BAS Q

Category Topic Question #

Acquisition Asset Management 1

Acquisition Contracts 2

BAS General Acronym 3

BAS General General Inquiries 4
BAS General General Inquiries 5

BAS General General Inquiries 6

BAS General Implementation 7

BAS General Overview 8

BAS General Policy and Processes 9

BAS General Scope 10

BAS General Staffing 11

BAS General Vendor 12

BAS General Why BAS 13

EDW Reporting 14

Accounting Code
Finance Classification String 15
(ACCS)

Finance Budgeting 16

Workshops and
BAS General 17
Discussions

Grants Data Integration 18

OCM Role Access 19

Property Real Property 20

Property Sunflower 21

Security Access Controls 22

Solution Customization 23

Solution Disagreements 24

Solution Disagreements 25

Solution Feature prioritization 26

Solution Standardization 27

Solution Systems 28
 Solution Systems and Tools 29

Testing Approach 30

Training Training Content 31

Training Training Options 32

Training Training Responsibilities 33

Acquisition Commitment 34
Accounting

EDW Legacy Data 35

Finance Repository Portal 36

Finance Penalties 37
 Finance Offset Research 38

Finance Project/ Task Codes 39

EDW Travel 40

Acquisition Legacy Data 41

EDW Reporting 42

BAS General BAS Documentation 43

Finance Project/ Task Codes 44

Finance KDDs 45

Finance e-invoice 46

Acquisition Electronic signatures 47

Finance e-invoice 48
 Acquisition Contracts 49

EDW Reporting 50

Finance Funds Obligation 51

Finance Workflow 52

Finance Cost Allocation 53

Technology, Architecture Access Controls 54

BAS General Staffing 55

Finance Data Integration 56

Acquisition Electronic signatures 57

Finance Project 101 58

 Finance e-invoice 59

OCM Q&A Office Hours 60

EDW Reporting 61

Property Requirements 62

Property Requirements 63

Risk Risk Register 64

Acquisition Records Repository 65

Finance Auto Accounting 66

Finance Freight 67

Business Process -
Finance 68
Receivables

Finance Collections 69

Finance Sales Rep Seeded Value 70

Finance Line and Transaction 71

Types
Finance Revenue Recognition 72

Finance Line and Item Type 73

Finance Auto Invoice 74

Finance Auto Invoice 75

Finance Reimbursables 76

Finance Reporting 77

Accounts Receivable and

Finance 78
Accounts Payable

Finance Adjustments 79

Finance Dunning 80

Finance Invoicing 81
Finance Data Validation 82

Finance Invoicing 83

Finance Invoicing 84
Finance Data Validation 85

Finance Invoice Types 86

Finance Invoice - no-match 87

Finance Obligations 88

Finance Create Accounting 89

Finance Data Interfaces 90

Finance Correction button 91

Finance Data Integration 92

Finance Payments 93

Finance Payments 94
 Intra-Government
Finance Payment and Collection 95
(IPAC)

Finance Process Flow 96

Finance Penalties and Discounts 97

Finance 1099 98

Finance 1099 99

Finance Prompt Pay 100

Finance Workflow 101

Finance Approvals 102

Finance Approvals 103

Finance Workflow 104

Finance CD-435 105

Intra-Government
Finance Payment and Collection 106
(IPAC)

Finance Unit of Measure (UOM) 107

Finance Line of Accounting 108

Finance Invoicing 109

Finance Tolerance 110

Finance 3-way match 111
Finance Tolerance 112
Finance Interest 113

Finance Payment Dates 114

Finance Travel Invoices 115

Finance Process Flow 116

Finance Adjustments 117

Finance Deobligation 118

Finance Reporting 119

Invoice Validation and

Finance Approval 120

Invoice Validation and

Finance 121
Approval

Finance Approvals 122

Finance Approvals 123

 Invoice Validation and
Finance 124
Approval

Finance Invoice Holds 125

Finance Invoice Holds 126

Finance Funds Obligation 127

Finance General Ledger 128

Finance General Ledger 129

Finance Disbursement 130

Finance Invoice Attachments 131

Finance Legislative Holds 132

Finance Records Repository 133

Finance Invoice Attachments 134

Finance Tolerance 135

Finance Partial Payment 136

Finance Data Access 137

Finance Invoice Numbers 138

Finance Banking Information 139

Finance Line of Accounting 140

Finance Payment Reconciliation 141

EDW MARS 142

EDW Standardization 143

EDW Data Gaps 144

EDW Reporting 145

EDW Data Integration 146

EDW Legacy Data 147

EDW Data Availability 148

EDW Position Planning 149

EDW Labor/ Employee Data 150

EDW Production Updates 151

EDW Budget BI Mart 152

EDW Reporting 153

EDW Data Interfaces 154

EDW Data Interfaces 155

EDW Data Availability 156

EDW Reporting 157

 Acquisition Information
EDW 158
Management (AIM)

EDW Documents 159

Community Powered BI
EDW 160
Marts

EDW Budget Requirements 161

Workshops and
EDW 162
discussions

EDW Outbound Data 163

EDW Data Availability 164

EDW Enterprise Services (ES) 165

EDW Data Integration 166

EDW Standardization 167

EDW ATO 168

EDW Data Availability 169

EDW Data Availability 170

EDW Data Interfaces 171

EDW Community Powered BI 172

Marts

EDW Requirements 173

EDW Data Availability 174

EDW Standardization 175

 EDW BI Tool 176

Finance Reporting 177

Finance Transaction Code 178

Finance Cost Centers 179

Acquisition Obligations 180

Finance Vendor 181

EDW BI Data Mart 182

Finance e-invoice 183

 Risk Issue 184

EDW MARS 185

Property Testing 186

Finance Payments 187

Finance ACS 188

EDW Reporting 189

Finance G-Invoicing 190

EDW Reporting 191

EDW Reporting 192

Finance Projects/Tasks 193

 Property Edits and Updates 194

Property Leases 195

Property Reconciliation 196

Property SSO 197

Property Network Discovery Tools 198

EDW Reporting 199

Technology, Architecture BAS Portal 200

Technology, Architecture Continuity of Operations 201

Finance Troubleshooting 202

Security ATO HVA 203

OCM General Inquiries 204

Security Security discussions 205

BAS General Discussions 206

Risk Risk Dashboard 207

Technology, Architecture Documentation 208

BAS General BAS PMO 209

BAS General Menti.com 210

 Finance Implementation Period 211

Acquisition UEI 212

Acquisition DUNS 213

Finance Estimated Accrual (EA) 214

EDW EDW fields 215

Budget Operating Plan

Finance 216
(BOP)

Finance Test Environment 217

Finance NIST Implementation 218

Finance Reporting 219

Data Migration and

Real Property 220
Legacy Data

Finance Reporting 221

Acquisition VPN 222

Finance Legacy Data 223

Acquisition User Acceptance Testing 224

Acquisition ATO 225

Finance Data Queries 226

Finance Census Implementation 227

Finance Global Data Table 228

BAS General Q&A Office Hours 229

Finance Demonstration 230

EDW Reporting 231

 EDW Reporting 232

Finance Reporting 233

EDW Record Repository 234

Technical BAS Portal 235

Finance EBS 236

Real Property Deployment 237

Tech/Arch Review and Comment 238

EDW Environment 239

OCM Town Hall 240

OCM BAS Website 241

BAS PMO Program Schedule 242

OCM Q&A's 243

Real Property IUS 244

Mary Beth Summary Level Transfer 245

 OCM Directory 246

BAS PMO Implementation Plan 247

EDW NFC 248

Commitment
Acquisition 249
Accounting

OCM Q&A's 250

Tech/Arch BAS Portal 251

Finance Bankcard and Grants 252

EDW Power User 253

OCM Common Solution 254

Travel and Purchase

Finance 255
Cards

BAS Website Project Timeline 256

EDW Power Users 257

Finance Data Availability 258

 Finance Reporting 259

Finance API Interfaces 260

EDW Tableau 261

EDW Query 262

OCM Q&A's 263

Commitment
EDW 264
Accounting

EDW Power Users 265

Finance Labor Estimates 266

EDW Tableau 267

Common Solution Configuration 3000

Common Solution Journal Entry 3001

Common Solution Approvals 3002
Common Solution Posting 3003

Common Solution Posting 3004

Common Solution Configuration 3005

Common Solution CVS Adjustments 3006

Common Solution CVS Adjustments 3007

Common Solution CVS Adjustments 3008

Common Solution CVS Adjustments 3009

Common Solution CVS Adjustments 3010

Common Solution CVS Adjustments 3011

Common Solution CVS Adjustments 3012

Common Solution CVS Adjustments 3013

Common Solution CVS Adjustments 3014

Common Solution Adjustments 3015

Common Solution Adjustments 3016

Common Solution Adjustments 3017

Common Solution Adjustments 3018

Common Solution Adjustments 3019

Common Solution Adjustments 3020

Common Solution Adjustments 3021

Common Solution Adjustments 3022

Common Solution Adjustments 3023

Common Solution Adjustments 3024

Common Solution Adjustments 3025

Common Solution Adjustments 3026

Common Solution Adjustments 3027

Common Solution Adjustments 3028

Common Solution Adjustments 3029

Common Solution Receipts and Collections 3030

(CVS)

Receipts and Collections

Common Solution 3031
(CVS)

Receipts and Collections

Common Solution 3032
(CVS)

Receipts and Collections

Common Solution 3033
(CVS)
Receipts and Collections
Common Solution 3034
(CVS)
Receipts and Collections
Common Solution 3035
(CVS)

Receipts and Collections

Common Solution 3036
(CVS)

Receipts and Collections

Common Solution 3037
(CVS)
Receipts and Collections
Common Solution (CVS) 3038

Receipts and Collections

Common Solution 3039
(CVS)

Receipts and Collections

Common Solution 3040
(CVS)
 Receipts and Collections
Common Solution 3041
(CVS)

Receipts and Collections

Common Solution 3042
(CVS)

Receipts and Collections

Common Solution 3043
(CVS)
Receipts and Collections
Common Solution 3044
(CVS)

Receipts and Collections

Common Solution (CVS) 3045

Receipts and Collections

Common Solution 3046
(CVS)

Common Solution Receipts and Collections 3047

(CVS)

Common Solution Receipts and Collections 3048

(CVS)

Receipts and Collections

Common Solution 3049
(CVS)

Receipts and Collections

Common Solution 3050
(CVS)

Common Solution PTP 3051

Common Solution PTP 3052

Common Solution PTP 3053

Common Solution PTP 3054

Common Solution PTP 3055

Common Solution PTP 3056

Common Solution PTP 3057

Common Solution PTP 3058

Common Solution PTP 3059

Common Solution PTP 3060

Common Solution PTP 3061

Common Solution PTP 3062

Common Solution PTP 3063

Common Solution PTP 3064

Common Solution PTP 3065

Common Solution PTP 3066

Common Solution PTP 3067

Common Solution PTP 3068

Common Solution PTP 3069

Common Solution PTP 3070

Common Solution PTP 3071

Common Solution PTP 3072

Common Solution PTP 3073

Common Solution PTP 3074

Common Solution PTP 3075

Common Solution PTP 3076

Common Solution PTP 3077

Common Solution PTP 3078

Common Solution PTP 3079

Common Solution PTP 3080

Common Solution PTP 3081

Common Solution PTP 3082

Common Solution PTP 3083

Common Solution PTP 3084

Common Solution PTP 3085

Common Solution PTP 3086

Common Solution PTP 3087

Common Solution PTP 3088

Common Solution PTP 3089

Common Solution PTP 3090

Common Solution PTP 3091

Common Solution PTP 3092

Common Solution PTP 3093

Common Solution PTP 3094

Common Solution PTP 3095

Common Solution PTP 3096

Common Solution PTP 3097

Common Solution PTP 3098

Common Solution PTP 3099

Common Solution PTP 3100

Common Solution PTP 3101

Common Solution PTP 3102

Common Solution PTP 3103

Common Solution PTP 3104

Common Solution PTP 3105

Common Solution PTP 3106

Common Solution PTP 3107

Common Solution PTP 3108

Common Solution PTP 3109

Common Solution PTP 3110

Common Solution PTP 3111

Common Solution PTP 3112

Common Solution PTP 3113

Common Solution PTP 3114

Common Solution PTP 3115

Common Solution PTP 3116

Common Solution PTP 3117

Common Solution PTP 3118

Common Solution PTP 3119

Common Solution PTP 3120

Common Solution PTP 3121

Common Solution PTP 3122

Common Solution PTP 3123

Common Solution PTP 3124

Common Solution PTP 3125

Common Solution PTP 3126

Common Solution PTP 3127

Common Solution PTP 3128

Common Solution PTP 3129

Common Solution PTP 3130

Common Solution PTP 3131

Common Solution PTP 3132

Common Solution PTP 3133

Common Solution PTP 3134

Common Solution PTP 3135

Common Solution PTP 3136

Common Solution PTP 3137

Common Solution PTP 3138

Common Solution PTP 3139

Common Solution PTP 3140

Common Solution PTP 3141

Common Solution PTP 3142

Common Solution PTP 3143

Common Solution PTP 3144

G-Invoicing - GT&C
Common Solution 3145
Process

G-Invoicing - GT&C
Common Solution 3146
Process

G-Invoicing - GT&C
Common Solution 3147
Process

G-Invoicing - GT&C
Common Solution 3148
Process

G-Invoicing - GT&C
Common Solution 3149
Process

G-Invoicing - GT&C
Common Solution 3150
Process

Common Solution Reporting and Analysis 3151

Common Solution Reporting and Analysis 3152

Common Solution Reporting and Analysis 3153

Common Solution Reporting and Analysis 3154

Common Solution Reporting and Analysis 3155

Common Solution Reporting and Analysis 3156

Common Solution Reporting and Analysis 3157

Common Solution Reporting and Analysis 3158

Common Solution Reporting and Analysis 3159

Common Solution Reporting and Analysis 3160

Common Solution Reporting and Analysis 3161

OTC Reporting and Analysis 3162

OTC Reporting and Analysis 3163

OTC Reporting and Analysis 3164

OTC Reporting and Analysis 3165

OTC Reporting and Analysis 3166

OTC Reporting and Analysis 3167

OTC Reporting and Analysis 3168

OTC Reporting and Analysis 3169

OTC Reporting and Analysis 3170

OTC Reporting and Analysis 3171

 OTC Reporting and Analysis 3172

OTC Reporting and Analysis 3173

OTC Reporting and Analysis 3174

OTC Reporting and Analysis 3175

OTC Reporting and Analysis 3176

OTC Reporting and Analysis 3177

Common Solution Code 3178

Common Solution Code 3179

Common Solution Code 3180

Common Solution Code 3181

Common Solution Structure 3182

Common Solution Structure 3183
Common Solution Code 3184

Common Solution BAS PMO 3185

Common Solution Code 3186

Common Solution Code 3187

Common Solution Budgeting 3188

Common Solution BAS PMO 3189

Common Solution Code 3190

Common Solution Transaction Code 3191

Common Solution Transaction Code 3192
Common Solution Code 3193

Common Solution Access Controls 3194

Common Solution Structure 3195

Common Solution Sub Accounts 3196

Common Solution Reporting and Analysis 3197

Common Solution Sub Accounts 3198

Common Solution Reporting and Analysis 3199

Common Solution BAS PMO 3200

Common Solution Budgeting 3201

Common Solution Reporting and Analysis 3202

Common Solution Object Class 3203

Common Solution Object Class 3204

Common Solution Reporting and Analysis 3205

Common Solution BAS PMO 3206

Common Solution Funds 3207

Common Solution BAS PMO 3208

Common Solution BAS Portal 3209

Common Solution General Inquiries 3210

Common Solution Funds 3211

 Accounting Code
Common Solution Classification String 3212
(ACCS)
Accounting Code
Common Solution Classification String 3213
(ACCS)

Common Solution Budgeting 3214

Common Solution Configuration 3215

Common Solution Reporting and Analysis 3216

Common Solution Funds 3217

Common Solution Funds 3218

Common Solution Funds 3219

Common Solution Funds 3220

Common Solution Auto Accounting 3221

Common Solution Funds 3222

Common Solution Funds 3223

Common Solution Funds 3224

Common Solution Access Controls 3225

Common Solution Structure 3226

Common Solution Funds 3227

Common Solution Funds 3228

Common Solution Reporting and Analysis 3229

Common Solution Funds 3230

Common Solution Code 3231

Common Solution Funds 3232

Common Solution Reporting and Analysis 3233

Common Solution BAS PMO 3234

Common Solution Code 3235

Common Solution BAS PMO 3236

Common Solution Code 3237

Common Solution Funds 3238

Common Solution Structure 3239

Common Solution Code 3240

Common Solution Structure 3241

Common Solution Structure 3242

Common Solution BAS Portal 3243

Common Solution Code 3244

Common Solution Code 3245

Common Solution Code 3246

Accounting Code
Common Solution Classification String 3247
(ACCS)

Common Solution Funds 3248

Common Solution Funds 3249

Common Solution Code 3250

Common Solution Code 3251

Common Solution Structure 3252

Common Solution Funds 3253

Common Solution Structure 3254

Common Solution Funds 3255

Common Solution Funds 3256

Common Solution Funds 3257

Common Solution Transaction Code 3258

Common Solution Code 3259

Common Solution Funds 3260

Common Solution Funds 3261

Common Solution Funds 3262

Accounts Receivable and

Common Solution 3263
Accounts Payable

Common Solution Funds 3264

Common Solution Funds 3265

Common Solution Funds 3266

Common Solution BAS Portal 3267

Common Solution Funds 3268

Common Solution Funds Obligation 3269

Common Solution ACS 3270

Common Solution Code 3271

Common Solution Code 3272

Common Solution Code 3273

Common Solution Code 3274

Common Solution Funds 3275

Common Solution Funds 3276

Common Solution Code 3277

Common Solution Funds 3278

Common Solution Code 3279

Common Solution Code 3280

Common Solution Code 3281

Common Solution Code 3282

Common Solution Structure 3283

Common Solution Code 3284

Common Solution Structure 3285

Common Solution Approvals 3286

Common Solution BAS Portal 3287

Common Solution Journal Entry 3288

Common Solution BAS PMO 3289

Common Solution Journal Entry 3290

Common Solution Journal Entry 3291

Common Solution Reporting and Analysis 3292

Common Solution Funds 3293

Common Solution Journal Entry 3294

Common Solution Journal Entry 3295

Common Solution BAS Portal 3296

Common Solution Funds 3297

Common Solution Journal Entry 3298

Common Solution Approvals 3299

Common Solution Journal Entry 3300

Common Solution Line of Accounting 3301

Common Solution Journal Entry 3302
Common Solution Journal Entry 3303

Common Solution Journal Entry 3304

Common Solution Journal Entry 3305

Common Solution Demonstration 3306

Common Solution Journal Entry 3307

Common Solution Reporting and Analysis 3308

Common Solution Journal Entry 3309

Common Solution Journal Entry 3310

Common Solution CVR 3311

Common Solution CVR 3312

Common Solution CVR 3313
Common Solution CVR 3314

Common Solution CVR 3315

Common Solution CVR 3316

Common Solution CVR 3317

Common Solution CVR 3318

Common Solution CVR 3319

Common Solution CVR 3320

Common Solution CVR 3321

Common Solution CVR 3322

Common Solution CVR 3323

Common Solution CVR 3324

Common Solution CVR 3325

Common Solution CVR 3326

Common Solution CVR 3327

Common Solution CVR 3328

Common Solution CVR 3329

Common Solution CVR 3330

Common Solution CVR 3331
Common Solution CVR 3332

Common Solution Ledger 3333

Common Solution Ledger 3334

Common Solution Ledger 3335

Common Solution Ledger 3336

Common Solution Ledger 3337

Common Solution Ledger 3338

Common Solution Ledger 3339

Common Solution Ledger 3340

Common Solution Ledger 3341

Common Solution Ledger 3342

Common Solution Ledger 3343

Common Solution Ledger 3344

Common Solution Ledger 3345

Common Solution Ledger 3346

Common Solution Ledger 3347

Common Solution Ledger 3348

Common Solution Ledger 3349

Common Solution Ledger 3350

Common Solution Ledger 3351

Common Solution Ledger 3352

Common Solution Ledger 3353

Common Solution Ledger 3354

Common Solution Ledger 3355

Common Solution Ledger 3356

Common Solution Projects 3357

Common Solution Projects 3358

Common Solution Projects 3359

Common Solution Projects 3360

Common Solution Projects 3361

Common Solution Projects 3362

Common Solution Projects 3363

Common Solution Projects 3364

Common Solution Projects 3365

Common Solution Projects 3366

Common Solution Projects 3367

Common Solution Projects 3368

Common Solution Projects 3369

Common Solution Projects 3370

Common Solution Projects 3371

Common Solution Projects 3372

Common Solution Projects 3373

Common Solution Projects 3374

Common Solution Projects 3375

Common Solution Projects 3376

Common Solution Projects 3377

Common Solution Projects 3378

Common Solution Projects 3379

Common Solution Projects 3380

Common Solution Projects 3381

Common Solution Projects 3382

Common Solution Projects 3383

Common Solution Projects 3384

Common Solution Projects 3385

Common Solution Projects 3386

Common Solution Projects 3387

Common Solution Projects 3388

Common Solution Projects 3389

Common Solution Projects 3390

Common Solution Projects 3391

Common Solution Projects 3392

Common Solution Projects 3393

Common Solution Projects 3394

Common Solution Projects 3395

Common Solution Projects 3396

Common Solution Projects 3397
Common Solution Projects 3398

Common Solution Projects 3399

Common Solution Projects 3400

Common Solution Projects 3401

Common Solution Projects 3402

Common Solution PTP 3403

Common Solution PTP 3404

Common Solution PTP 3405

Common Solution PTP 3406

Common Solution PTP 3407

Common Solution PTP 3408

Common Solution PTP 3409

Common Solution PTP 3410

Common Solution PTP 3411

Common Solution PTP 3412

Common Solution PTP 3413

Common Solution PTP 3414

Common Solution PTP 3415

Common Solution PTP 3416

Common Solution PTP 3417

Common Solution PTP 3418

Common Solution PTP 3419

Common Solution PTP 3420

Common Solution PTP 3421

Common Solution PTP 3422

Common Solution PTP 3423

Common Solution PTP 3424

Common Solution PTP 3425

Common Solution PTP 3426

Common Solution PTP 3427

Common Solution PTP 3428

Common Solution PTP 3429

Common Solution PTP 3430

Common Solution PTP 3431

Common Solution PTP 3432

Common Solution PTP 3433

Common Solution PTP 3434
Common Solution PTP 3435

Common Solution PTP 3436

Common Solution PTP 3437

Common Solution PTP 3438

Common Solution PTP 3439

Common Solution PTP 3440

Common Solution PTP 3441

Common Solution PTP 3442

Common Solution PTP 3443

Common Solution PTP 3444

Common Solution PTP 3445

Common Solution PTP 3446

Common Solution PTP 3447

Common Solution PTP 3448

Common Solution PTP 3449

Common Solution PTP 3450

Common Solution PTP 3451

Common Solution PTP 3452

Common Solution PTP 3453

Common Solution PTP 3454

Common Solution PTP 3455

Common Solution PTP 3456

Common Solution PTP 3457

Common Solution PTP 3458

Common Solution PTP 3459

Common Solution PTP 3460

Common Solution PTP 3461

Common Solution PTP 3462

Common Solution PTP 3463
Common Solution PTP 3464

Common Solution PTP 3465

Common Solution PTP 3466

Common Solution PTP 3467

Common Solution PTP 3468

Common Solution PTP 3469

Common Solution PTP 3470

Common Solution PTP 3471

Common Solution PTP 3472

Common Solution PTP 3473

Common Solution PTP 3474

Common Solution PTP 3475

Common Solution PTP 3476

Common Solution PTP 3477

Common Solution PTP 3478

Common Solution PTP 3479

Common Solution PTP 3480

Common Solution PTP 3481

Common Solution PTP 3482

Common Solution PTP 3483

Common Solution PTP 3484

Common Solution PTP 3485

Common Solution PTP 3486

Common Solution PTP 3487

Common Solution PTP 3488

Common Solution PTP 3489

Common Solution PTP 3490

Common Solution PTP 3491

Common Solution PTP 3492

Common Solution PTP 3493

Common Solution PTP 3494

Common Solution PTP 3495

Common Solution PTP 3496

Common Solution PTP 3497
Common Solution PTP 3498

Common Solution PTP 3499

Common Solution PTP 3500

Common Solution PTP 3501

Common Solution PTP 3502

Common Solution PTP 3503

Common Solution PTP 3504

Common Solution PTP 3505

Common Solution PTP 3506

Common Solution PTP 3507

Common Solution PTP 3508
Common Solution PTP 3509

Common Solution PTP 3510

Common Solution PTP 3511

Common Solution PTP 3512

Common Solution PTP 3513

Common Solution PTP 3514

Common Solution PTP 3515

Common Solution PTP 3516

Common Solution PTP 3517

Common Solution PTP 3518

Common Solution PTP 3519

Common Solution PTP 3520

Common Solution PTP 3521

Common Solution PTP 3522

Common Solution PTP 3523

Common Solution PTP 3524

Common Solution PTP 3525

Common Solution PTP 3526

Common Solution PTP 3527

Common Solution PTP 3528

Common Solution PTP 3529

Common Solution PTP 3530

Common Solution PTP 3531

Common Solution PTP 3532

Common Solution PTP 3533

OTC Reporting and Analysis 3534

OTC Reporting and Analysis 3535

OTC Reporting and Analysis 3536

OTC Reporting and Analysis 3537

OTC Reporting and Analysis 3538

OTC Reporting and Analysis 3539

OTC Reporting and Analysis 3540

OTC Reporting and Analysis 3541

OTC Reporting and Analysis 3542

OTC Reporting and Analysis 3543

OTC Reporting and Analysis 3544

OTC Reporting and Analysis 3545

OTC Reporting and Analysis 3546

 Receipts and Collections
Common Solution 3547
(CVS)

Receipts and Collections

Common Solution 3548
(CVS)

Receipts and Collections

Common Solution 3549
(CVS)

Receipts and Collections

Common Solution 3550
(CVS)

Receipts and Collections

Common Solution (CVS) 3551

Receipts and Collections

Common Solution 3552
(CVS)

Receipts and Collections

Common Solution 3553
(CVS)

Receipts and Collections

Common Solution 3554
(CVS)

Budget Entry/Funds
Common Solution 3555
Status Deep Dive

Budget Entry/Funds
Common Solution 3556
Status Deep Dive
 Budget Entry/Funds
Common Solution 3557
Status Deep Dive

Budget Entry/Funds
Common Solution 3558
Status Deep Dive

Budget Entry/Funds
Common Solution 3559
Status Deep Dive

Budget Entry/Funds
Common Solution 3560
Status Deep Dive

Budget Entry/Funds
Common Solution Status Deep Dive 3561

Common Solution OTC 3562

Common Solution OTC 3563

Common Solution OTC 3564

Common Solution OTC 3565

Common Solution OTC 3566

Common Solution OTC 3567

Common Solution OTC 3568

Common Solution OTC 3569

Common Solution OTC 3570

Common Solution OTC 3571

Common Solution OTC 3572

Common Solution OTC 3573

Common Solution OTC 3574

Common Solution OTC 3575

Common Solution OTC 3576

Common Solution OTC 3577

Common Solution OTC 3578

Common Solution Customer Refunds 3579

Common Solution Customer Refunds 3580

Common Solution Customer Refunds 3581

Common Solution Customer Refunds 3582

Common Solution Customer Refunds 3583

Common Solution Customer Refunds 3584

Common Solution Customer Refunds 3585

Common Solution Customer Refunds 3586

Common Solution Customer Refunds 3587

Common Solution Customer Refunds 3588

Common Solution Customer Refunds 3589

Common Solution Customer Refunds 3590

Common Solution Customer Refunds 3591

Common Solution Customer Refunds 3592

Common Solution Customer Refunds 3593

Common Solution Customer Refunds 3594

Credit/Debit
Common Solution 3595
Memos/Refunds
Common Solution Credit/Debit 3596
Memos/Refunds

Credit/Debit
Common Solution 3597
Memos/Refunds

Credit/Debit
Common Solution 3598
Memos/Refunds

Credit/Debit
Common Solution 3599
Memos/Refunds

Credit/Debit
Common Solution 3600
Memos/Refunds
Credit/Debit
Common Solution 3601
Memos/Refunds
Credit/Debit
Common Solution 3602
Memos/Refunds
 Job Aids for SAMS RP
Real Property 3603
Functionality

BAS Real Property

Real Property Change and Control 3604
Board

Enhancement Request
Real Property 3605
Clarification

Real Property FRPP Testing Schedule 3606

Training Documentation
Real Property 3607
Updates

Common Solution Receipts 3608

Common Solution Receipts 3609

Common Solution Receipts 3610

Common Solution Receipts 3611

Common Solution Receipts 3612

Common Solution Receipts 3613

Common Solution Receipt Remittance 3614

Common Solution Receipt Remittance 3615

Common Solution Receipt Remittance 3616

Common Solution Receipt Remittance 3617

Common Solution Receipt Remittance 3618

Common Solution Receipt Remittance 3619

Common Solution Receipt Remittance 3620

Common Solution Receipt Remittance 3621

Common Solution Receipt Remittance 3622

Common Solution Receipt Remittance 3623

Common Solution Receipt Remittance 3624

Common Solution Receipt Remittance 3625

Common Solution Receipt Remittance 3626

Common Solution Receipt Remittance 3627

Common Solution Receipt Remittance 3628

Common Solution Receipt Remittance 3629

Common Solution Receipt Remittance 3630

Common Solution Receipt Remittance 3631

Common Solution Receipt Remittance 3632

Common Solution Receipt Remittance 3633

Receipt Remittance
Common Solution Follow Up 3634

Receipt Remittance
Common Solution 3635
Follow Up

Receipt Remittance
Common Solution Follow Up 3636

Receipt Remittance
Common Solution 3637
Follow Up

Receipt Remittance
Common Solution 3638
Follow Up
 Receipt Remittance
Common Solution 3639
Follow Up

Receipt Remittance
Common Solution Follow Up 3640

Receipt Remittance
Common Solution 3641
Follow Up

Receipt Remittance
Common Solution Follow Up 3642

(GINV) Interagency
Common Solution Agreements​: Servicing 3643
Agency

(GINV) Interagency
Common Solution Agreements​: Servicing 3644
Agency

(GINV) Interagency
Common Solution Agreements​: Servicing 3645
Agency

(GINV) Interagency
Common Solution Agreements​: Servicing 3646
Agency
 (GINV) Interagency
Common Solution Agreements​: Servicing 3647
Agency

(GINV) Interagency
Common Solution Agreements​: Servicing 3648
Agency

(GINV) Interagency
Common Solution Agreements​: Servicing 3649
Agency

(GINV) Interagency
Common Solution Agreements​: Servicing 3650
Agency

(GINV) Interagency
Common Solution Agreements​: Servicing 3651
Agency

(GINV) Interagency
Common Solution Agreements​: Servicing 3652
Agency

(GINV) Interagency
Common Solution Agreements​: Servicing 3653
Agency
 (GINV) Interagency
Common Solution Agreements​: Servicing 3654
Agency

(GINV) Interagency
Common Solution Agreements​: Servicing 3655
Agency

(GINV) Interagency
Common Solution Agreements​: Servicing 3656
Agency

(GINV) Interagency
Common Solution Agreements​: Servicing 3657
Agency

(GINV) Interagency
Common Solution Agreements​: Servicing 3658
Agency

(GINV) Interagency
Common Solution Agreements​: Servicing 3659
Agency

Common Solution ACS Part 3 3660

Common Solution ACS Part 3 3661

Common Solution ACS Part 3 3662

Common Solution ACS Part 3 3663

Common Solution ACS Part 3 3664

Common Solution ACS Part 3 3665

Common Solution ACS Part 3 3666

Common Solution ACS Part 3 3667

Common Solution ACS Part 3 3668

Common Solution ACS Part 3 3669

Common Solution ACS Part 3 3670

Common Solution ACS Part 3 3671

Common Solution ACS Part 3 3672

Common Solution ACS Part 3 3673

Common Solution ACS Part 3 3674

Common Solution ACS Part 3 3675

Common Solution ACS Part 3 3676

Common Solution ACS Part 3 3677

Common Solution ACS Part 3 3678

Common Solution ACS Part 3 3679

Common Solution ACS Part 3 3680

Common Solution ACS Part 3 3681

Common Solution ACS Part 3 3682

Common Solution ACS Part 3 3683

Common Solution ACS Part 3 3684

Common Solution ACS Part 3 3685

Common Solution ACS Part 3 3686

Common Solution ACS Part 3 3687

Common Solution ACS Part 3 3688

Common Solution ACS Part 3 3689

Common Solution ACS Part 3 3690

Common Solution ACS Part 3 3691

Common Solution ACS Part 3 3692

Common Solution ACS Part 3 3693

Common Solution ACS Part 3 3694

Common Solution ACS Part 3 3695

Common Solution ACS Part 3 3696

Common Solution ACS Part 3 3697

Common Solution ACS Part 3 3698

Common Solution ACS Part 3 3699

Common Solution ACS Part 3 3700

Common Solution ACS Part 3 3701

Common Solution ACS Part 3 3702

Common Solution ACS Part 3 3703

Common Solution ACS Part 3 3704

Common Solution ACS Part 3 3705

Common Solution ACS Part 3 3706

Common Solution ACS Part 3 3707

Common Solution ACS Part 3 3708

Common Solution ACS Part 3 3709

Common Solution ACS Part 3 3710

Common Solution ACS Part 3 3711

Common Solution ACS Part 3 3712

Common Solution ACS Part 3 3713

Common Solution ACS Part 3 3714

Common Solution GTAS/DATA Act 3715

Common Solution GTAS/DATA Act 3716

Common Solution GTAS/DATA Act 3717

Common Solution GTAS/DATA Act 3718

Common Solution GTAS/DATA Act 3719

Common Solution GTAS/DATA Act 3720

Common Solution GTAS/DATA Act 3721

Common Solution GTAS/DATA Act 3722

Common Solution GTAS/DATA Act 3723

Common Solution GTAS/DATA Act 3724

Common Solution GTAS/DATA Act 3725

GTAS and DATA Act

Common Solution 3726
Reporting

GTAS and DATA Act

Common Solution 3727
Reporting

Common Solution GTAS and DATA Act 3728

Reporting
 GTAS and DATA Act
Common Solution 3729
Reporting

GTAS and DATA Act

Common Solution 3730
Reporting

GTAS and DATA Act

Common Solution 3731
Reporting

GTAS and DATA Act

Common Solution 3732
Reporting

GTAS and DATA Act

Common Solution Reporting 3733

GTAS and DATA Act

Common Solution 3734
Reporting

GTAS and DATA Act

Common Solution 3735
Reporting

GTAS and DATA Act

Common Solution 3736
Reporting

GTAS and DATA Act

Common Solution Reporting 3737
Common Solution Month End Close 3738

Common Solution Month End Close 3739

Common Solution Month End Close 3740

Common Solution Month End Close 3741

Common Solution Month End Close 3742

Common Solution Month End Close 3743

Common Solution Month End Close 3744

Common Solution Month End Close 3745

Common Solution Month End Close 3746

Common Solution Month End Close 3747

Common Solution Month End Close 3748

Common Solution Month End Close 3749

Common Solution Month End Close 3750

Common Solution Month End Close 3751

Common Solution Month End Close 3752

Common Solution Month End Close 3753

Common Solution Month End Close 3754

Common Solution Month End Close 3755

Common Solution Month End Close 3756

Common Solution Month End Close 3757

Common Solution Month End Close 3758

Common Solution Month End Close 3759

Common Solution Month End Close 3760

Common Solution Month End Close 3761

Common Solution Month End Close 3762

Common Solution Month End Close 3763

Common Solution Month End Close 3764

Common Solution Month End Close 3765

Common Solution Month End Close 3766

Common Solution Month End Close 3767

SAM Vendor
Common Solution 3768
Management

SAM Vendor
Common Solution 3769
Management

SAM Vendor
Common Solution 3770
Management

SAM Vendor
Common Solution 3771
Management

SAM Vendor
Common Solution 3772
Management

Common Solution SAM Vendor 3773

Management
SAM Vendor
Common Solution 3774
Management
 SAM Vendor
Common Solution 3775
Management

SAM Vendor
Common Solution 3776
Management

SAM Vendor
Common Solution Management 3777

SAM Vendor
Common Solution 3778
Management

SAM Vendor
Common Solution 3779
Management

SAM Vendor
Common Solution 3780
Management

SAM Vendor
Common Solution 3781
Management

SAM Vendor
Common Solution 3782
Management

SAM Vendor
Common Solution 3783
Management
 SAM Vendor
Common Solution 3784
Management

Common Solution Pay.gov 3785

Common Solution Pay.gov 3786

Common Solution Pay.gov 3787

Common Solution PRISM - EBS Awards 3788

Common Solution PRISM - EBS Awards 3789

Common Solution PRISM - EBS Awards 3790

Common Solution PRISM - EBS Awards 3791

Common Solution PRISM - EBS Awards 3792

Common Solution PRISM - EBS Awards 3793

Common Solution PRISM - EBS Awards 3794

Common Solution PRISM - EBS Awards 3795

Common Solution PRISM - EBS Awards 3796

Common Solution PRISM - EBS Awards 3797

Common Solution PRISM - EBS Awards 3798

Common Solution PRISM - EBS Awards 3799

Common Solution PRISM - EBS Awards 3800

Common Solution SAM Vendors 3801

Common Solution SAM Vendors 3802

Common Solution SAM Vendors 3803

Common Solution SAM Vendors 3804
Common Solution SAM Vendors 3805

Common Solution SAM Vendors 3806

Common Solution SAM Vendors 3807

Common Solution SAM Vendors 3808

Common Solution SAM Vendors 3809

Common Solution SAM Vendors 3810

Common Solution SAM Vendors 3811

Year End Close

Common Solution 3812
Processing
 Year End Close
Common Solution Processing 3813

Year End Close

Common Solution 3814
Processing

Year End Close

Common Solution 3815
Processing

Year End Close

Common Solution Processing 3816

Year End Close

Common Solution 3817
Processing

Year End Close

Common Solution 3818
Processing
 Year End Close
Common Solution 3819
Processing

Year End Close

Common Solution 3820
Processing

Year End Close

Common Solution Processing 3821

Year End Close

Common Solution 3822
Processing

Common Solution Travel (CWT/E2) 3823

Common Solution Travel (CWT/E2) 3824

Common Solution Travel (CWT/E2) 3825

Common Solution Travel (CWT/E2) 3826

Common Solution Travel (CWT/E2) 3827

Common Solution Travel (CWT/E2) 3828

Common Solution Travel (CWT/E2) 3829

Common Solution Travel (CWT/E2) 3830

Common Solution Travel (CWT/E2) 3831

Common Solution Travel (CWT/E2) 3832

Common Solution Travel (CWT/E2) 3833

Common Solution Travel (CWT/E2) 3834

Common Solution Travel (CWT/E2) 3835

Common Solution Census 3836

Common Solution Census 3837

Common Solution Census 3838

Common Solution Projects 3839

Common Solution Projects 3840

Common Solution Projects 3841

Common Solution Projects 3842

Common Solution Projects 3843

Common Solution Projects 3844

Common Solution Projects 3845

Common Solution Projects 3846

Common Solution Projects 3847

Common Solution Projects 3848

Common Solution Projects 3849

Common Solution Projects 3850

Common Solution Projects 3851

Common Solution Projects 3852

Common Solution Projects 3853

Common Solution Projects 3854

Common Solution Projects 3855

 BAS Questions and Answers
Question

How will acquisition be developed in the BAS solution and will it

include software asset management?

Will BAS be the system of record for contracts and include records
management?

What does BAS stand for?

Who can I email if I have questions?
Can the slides for Town Halls and Table Talks be available on the
website and attached to the invitation?

Where can I go to get more information?

What is the timeline for BAS and the implementation phases?

What is the BAS Program?

What are the plans for O&M, e.g. policy and procedures for user
provisioning, month- and year-end close, system configuration
maintenance)?
What is the Scope of BAS and which bureaus will be included?

Can you share more information about the additional BAS PMO
positions and Detail positions?

Which vendor is supporting the BAS Program?

Why are we doing BAS?

How are reporting needs being captured?

Will a new standardized "Accounting Code Classification String

(ACCS)" be implemented?

Will budgeting be included in BAS?

How can I participate in the workshops or find out more about the
discussions within the workshop?

How will Grants be included in the BAS solution set?

How will Roles and Responsibilities be identified and controlled in

BAS?

Will the solution focus only on DOC minimum reporting

requirements or all bureau reporting and analysis requirements for
real property?
How will Sunflower fit in the BAS solution and what is the timeline?

Can you tell me about the security and access controls for BAS?

How will unique Bureau needs that require customization be

addressed?

How will disagreement between Bureau feedback be addressed?

Who will approve and sign off on the set of BAS requirements and
how will Bureau disagreements be addressed?

How will we prioritize and decide which features/desires will be

implemented?

To what degree will BAS provide a standardized solution, e.g. will

there be a set of books?

Were multiple applications considered for the BAS Program? What IT

solutions will BAS deploy?
What will happen to all the systems and tools that I use today?

What is the testing approach to ensure that requirements are being

met?

How will training needs be captured and addressed?

Due to lack of classrooms, the current COVID-19 environment, and

OCONUS users, will online training be offered as an option?

Who will do the initial BAS training (for Go-Live) and how will
training be handled post Go-Live?

Will PRISM have commitment accounting?

Will all of the several terabytes of legacy data needed by NIST from
CFS, Data Warehouse, and C. Suite applications be migrated into the
BAS data lake? Or will NIST need to maintain existing servers and
databases to store this data for many years?

Is BAS considering building a 1099/1042 repository portal for

taxpayers to directly retrieve this information instead of physically
mailing out in January from service bureaus (like NIST currently
does)?

Will BAS build in different sets of penalty calculations for interest

incurred for different length (e.g. less than 30 days simplify interest
and others compound interest)? What about utilities subject to
Prompt Payment Act, but under different penalty rules?
Will BAS link any post payment treasury application systems, e.g.
offset program, to shorten the research on payment inquiries from
vendor?

Not sure about the use of Project/task codes across all the different
BAS components. These drive much of NOAA's funding obligation
process from T&A to major procurements. Will there be a session to
discuss this?

Will reservation data that is not linked in E2 (e.g., only exists

CWT/Sato) be included in the BAS EDW? There are circumstances
when the reservation is not pulled into E2 and it would be helpful to
have this data in the EDW for analysis, oversight, and review
purposes.

Would all of the C. Suite Legacy data be integrated to PRISM? If not

what would happen to the data?

Different bureaus will need different reports. Will it be possible to

create these reports?

Could you share the Business Flow Diagram, Data Flow Diagram,
Data Dictionary, and Data Model on all three systems of PRISM,
Oracle Financial EBS, and BAS Property?

At NIST, projects, tasks, object classes are used to drive

programmatic reporting and general ledger postings. The Order to
Cash Common Solution working group needs to understand these
relationships. How will that information, including the use of flex
fields, discussed by independent working groups, be shared within
the various functional areas?

Will you be able to share the KDDs with the bureaus?

What steps would need to be taken to modify Dock contracts

language to require use of the e-Invoicing portal so vendors will
leverage a vendor-portal rather than emailing or mailing hard-copy
bills?

What steps would need to be taken to require electronic signatures

(internally or externally) so as to enable a paperless process? How
will BAS consume treasury IPAC workbooks or interface with G-
Invoicing to cover government-to-government?

What parts will BAS e-Invoicing cover? What parts (if any) won’t be
covered requiring bureaus to solution internally or alter our data
feed requests?
Will the BAS procurement solution have source data similar to
what's leveraged from CSTARS today - to avoid re-building data
feeds and maintenance of a separate process?

Will NIST's BusinessObjects implementation be able to access NIST

CFS, Data Warehouse, and C. Suite data after the data is migrated
into the BAS data lake?

In monitoring R&D obligations in CBS for audit, I've noticed that

someone can identify a project code as non R&D but then set the
Object class to Research Grants or R&D contracts. Also, the current
Contracting System requires R&D labels, but people can use non
R&D Contracting Object Classes. Can BAS have prompts or flags to
avoid this or guide users to the correct determination?

Will BAS EBS has the batch reassignment function or override

delegate function to allow back up to access the workload sitting in
other person's queue?

NOAA Acquisition and Grants Office receives a percentage fee from

each obligation on a Purchase Request based on the last four object
class code digits. Fees are automatically collected from each
accounting code using CBS templates in the surcharge process. Will
there be a similar process in BAS to collect fees automatically and
deposit them in an internal fund?

Will the BAS system available from the Internet?

If someone is interested in working on the BAS project, who is the

best person to contact?

OIG is moving from Office of Secretary's instance of WEB TA to

Treasury/ARC's instance. The data will still go to NFC and then to
NIST's instance of CBS. What should I look for to make sure there's
no issue with the data getting into BAS when the switchover occurs?

Related to digital signatures, could you please confirm if/that the

intent is for BAS to enable paperless process? (Steps beyond
PRISM)?

I missed the Project 101 discussion on 12/8/2020, will the materials

be posted on the BAS website?
Is this e-invoicing functionality for PRISM or EBS or both? Where can
invoices be submitted?

Will all Q&As from Office Hours (both questions pre-submitted and
those asked during the session) be posted on the BAS Website?

Will NIST have to rewrite or create new reports to obtain reports or

data from the legacy system in the BAS data lake

NOAA Personal Property has incorporated a lot of automation in our

processes. What will determine what gets kept and what goes away
with the single BAS Property solution and who will decide?

NOAA Personal Property has a different Property Official structure

than most other bureaus. How will this be managed in the BAS
Personal Property solution? Will BAS/Accenture work with each
bureau to review their processes?
Will you be able to share the Risk Register with the bureaus?

Does BAS and/or PRISM have a records repository (for contract

records/ records/proposals/etc.) or will we need to store contract
files in our own electronic file room?

Is Auto Accounting the same thing as TC codes in CBS?

NOAA would like to have further discussion around Freight and how
it is handled in Oracle EBS.

Once all bureaus are using the same Oracle EBS  instance - Do
receivables behave differently if they occur between DOC bureaus in
Oracle EBS?

Collections from CIR (ACH and credit card) - how will those be
processed in Oracle EBS?
Sales Rep Seeded Value is not applicable to NOAA based on the
description provided during the Common Solution Meeting.

What are the standard line and transaction types in Oracle EBS?
Please provide additional examples of revenue recognition.

Is Line Type in EBS the same as an Item Type in CBS?

Auto Invoice Rules - How will the additional sources from which
accounting is derived map over to Oracle EBS?
Auto Invoice Rules - Please provide a list of possible sources in Oracle
EBS and how do they map to the sources in the AR001 Billed
Receivables and AR009 Unbilled screens in CBS?

How would Reimbursable Work in Progress (WIP) be handled in

Oracle EBS?

For Reporting and Analysis - will this cover reporting for AR Billing?

Will the Oracle EBS module link the AR and AP modules?

Can you please provide a list of adjustments in Oracle EBS (e.g.,  

Refund, write off etc.)?

How will dunning be handled in Oracle EBS?

Will invoices submitted electronically for awards be addressed in

Sprint 3 Vendor Portal?
Will data validation be handled electronically in Oracle EBS?

Is the invoice created and matched against the PO receipt the same
as the PM003 in CBS?

Who enters the invoice data into Oracle EBS? Will it be manual?
How will Oracle EBS check that the data is correct? Where are the
controls in the system?

What are the invoice types in Oracle EBS so we can identify which
document should be processed? Will there be a receiving ticket,
estimated accruals etc.?

Can you describe the process for No-Match invoices in Oracle EBS?

With larger payments will the obligating document be available for

review and certification? How will obligating documents be
accessed? Will permissions be granted to review the obligating
documents?

What does "Create Accounting" mean in the process flow?

Data interface from CWT to CBS - is there a way to update the

invoice number to a parent account? Can payments be handled line
by line or this a way to handle corrections at one time?

What does the correction button do?

For all AP interfaces that rely on APSI processing - how will this be
accommodated in Oracle EBS? (e.g., SP3, MLINQs, FedEx/UPS, NWS
Telecom etc.….) How will the data be uploaded to the AP module for
payment processing or for gal posting only?
Upload of Data - into PM003 - this is not interfaced - how will this be
handled in Oracle EBS? (e.g., FedEx/UPS Payments)?
How will Oracle EBS be configured to set up frequent payments that
do not have invoices (PM020) (e.g., Recur Payments - Leases,
Observers etc. ?
What is the mechanism for recording IPAC invoices (generating for
income coming in and also for the accounts receivable expenses) in
Oracle EBS?

In reviewing the process flow, it appears it is high level and seems to

be missing some of the key decisions process flow elements
required. Further discussion is needed on this process flow before
NOAA can validate.

How will the system calculate discounts and interest penalties? Are
those customizable by document, invoice and item type? If so, how
and what would standard configuration be for DOC? Please provide
the specific configuration values that are established for Prompt Pay
and discounts, how they are controlled by document type, item type,
line type and what is the CM process for theses values by
bureau/department?

How is the payment determined to be 1099 reportable for tax

purposes?
Will EBS have a field to recognize 1099 filing status and how will this
process work in Oracle EBS?
How does the system identify if a transaction is subject to Prompt
Pay?

How will Oracle accommodate workflow in BAS?

How many levels of approval are available in workflow?

What is the review, receipt process and how it gets routed for more
than 1 level of approval?
Can workflow be different for each document type?

How will CD-435 documents be handled in Oracle EBS (obligating

docs that do not get processed or managed through PRISM)?

Please explain the manual IPAC process in Oracle EBS (in CBS it is the
PM041 process).

The example in Oracle shows Qty x Price to give an amount view.

Will the solution be dollar based vs. quantity based? How will
rounding issues be addressed? How will Prompt Pay be calculated?
In CBS for every line of accounting. there is a description of how it is
calculated - is there a note or a description field in Oracle EBS to
explain how the fields are calculated?
If there is a matched invoice can you have a combo of matched and
no matched line items?
How is tolerance calculated (e.g., travel) and how is it controlled at
an item or document level?
Who enters the receipt data for the 3-way match?
When tolerance is invoked can it be different based on line item
type?
How is interest handled in Oracle EBS?

How will the system determine the hierarchy of how the system is
configured to calculate dates? For example with interest penalties
(receiving ticket, receive invoice, process document etc.)? Which
date will be used for processing? Please clarify the date logic.

Travel CBA - matching payment to PO # = when PO is higher than

applied, the line is closed in CBS and NOAA has to create no match
lines. How will this work in Oracle EBS?
For all flows, please walk through in detail what each box means?
Doc types, line items what is interfaced, vendors online invoices etc.
- need to understand the implications

Adjustments - how will this be done for invoices - line of accounting

vs. DAR (change more than line of accounting)?

How will the system handle deobligations? Final receipt of an item or

invoice - how is this deobligated?
How will reporting for Accounts Payable be handled?

For invoice validation - how is this applicable to - 2 way, 3 way, 4 way

match?

Who is validating and who is approving invoices? Are they two

different people? If so, how are the various people notified?

Document management - will the system email the next person for
approval or processing of payment? Or will there be a queue to
identify what needs to occur next in the process? How will
notifications occur?

Which roles are currently responsible for validating and approving

doc invoices? Need to understand how to translate in future - not an
exhaustive list. See for buyer from purchasing side, requestor, COR -
limited to usually 2-3 people.
How will validating and approval of invoices occur today in Oracle
EBS? Will the responsibility of validating and approving invoices be
handled Acquisitions Office via PRISM or will the current process
continue where invoices are validated and approved in the Finance
Office?

For the approval process will this be automated or a manual paper

process?

What are seeded invoice holds?

Do invoice holds factor into Prompt Payments?

How do we put funding back into an Obligating document without

having to create a mod?

How will the user get a near real time view of the general ledger if
documents are batched from the subledger? Today in CBS we can
run Quick Reports to see the real time data and it pulls from the GL.

Can you change how frequently documents are pushed to the

General Ledger (especially around month end and year end)?

Explain the Disbursement Process in Oracle EBS

How long will attachments on invoices stay in the system? What are
the limitations that will be implemented so NOAA can obtain copies
of attachments and records? What is the file size limitation?

How can documents be flagged for "legislative holds" so that

attachments and documents be kept?

Will there be enough storage for record retention and legislative

holds?
Will there be a requirement to always attach an invoice in Oracle
EBS?

Is there a tolerance table in Oracle EBS?

Will partial payment occur if the individual line items for one invoice
are approved via the interface?

Will bureaus be limited to selecting only accounts within their

bureau?
Will BAS allow updates to the invoice number for interfaced invoices
at the end-user level?
If the supplier has multiple remittance for various contracts, where
do you select the banking to use for that invoice? Or is it assumed
you would always have a 1-to-1 relationship between the contract
and remittance information?
Can multiple line items with different accounting be added?
Is there a way to reconcile the day's payments at either the
individual level or at a group level?

Is all of MARS is out of scope?

Will there be discussions about data standardization?

EDW standardized data model - open docs, closed documents -
where does standardization fit into overall plan.

When will the discussion of current missing data objects be held to

determine GAPs that cause long response times to data calls /
reporting requirements?

Currently, there are robust Financial Operational reports (developed

out of necessity over the last 20 years). Are the EBS Operational
reports being mapped to current reports to determine what GAPs
might exist?

Will integrated data across the BI areas include key data needs such
as Period of Performance (POP) at the detail level; Place of
Performance (Award location versus Payment location versus where
work performed); Congressional Districts; multiple Project / Program
attributes (NSF, Research, Special Initiatives, Disaster tracking, Goal/
Program/Capability, etc.?
Will legacy data mapping to new EBS based mapping (CBS ACCS to
EBS ACS) be standardized in the EDW? How will this occur?

Copying Legacy CBS and C. Suite data for NOAA after go-live
indicates that we would be running legacy DW in parallel for at least
Q1 of FY23? Am I reading that correctly?

Can you please provide more details on Position Planning Dev &
Demo?

It is my understanding that NFC Labor/Employee will be discussed in

Sprint 3 FY21 Q3 for Core Applications. NFC is in the EDW Phase 1 -
Early Deployment FY21 Q2. How are we discussing NFC Labor in Q3
but it's in early deployment in Q2? Am I missing something?

Once we're in production, we'll recognize gaps in missing objects and

joins in production, will there be a process for making table updates?

Will the Budget Area include joining of data from Formulation, to

Appropriation, Allocation, Budget planning, Execution, etc. through
multiple years forward and backward?

Will there be cross reporting between the user areas? For instance,
we are continually be asked to join acquisition data with financial
data and grant data with financial data.

Where does ITA’s overseas data that flows through Department of

State data fit in? Is it included in NIST CBS?
ITA’s overseas data that flows through Department of State will be
ongoing. It is currently interfaced into NIST's CBS data. It needs to be
accounted for in the Inbound Data.

How can SAM not be in scope? We need to report on vendor type,

fed vs non-fed, etc. Will vendor data be in EDW?

Will EDW data be available via ServiceNow or Web Service?

I see "Ad hoc" reporting...will there be any collection of our current

reports to see if we can develop "Standard reports?" Standard
reports that all of us use and that can be developed once and for all
of us to use and placed into the EDW? Perhaps one example is the
Undelivered Order Report.
What is the AIM mentioned as "Not in Scope" for the Acquisition
Community?

Can you please clarify what copying over legacy data versus
documents means? Historical copy of documents shows that "only
current system data will be copied." Does this mean that only
documents in C. Suite will be moved to PRISM? Will official electronic
contract file documents that are not in C. Suite be transferred to
PRISM?

For awareness, budget users will likely need to access and analyze
data from across all of these communities (procurement, budget,
positions).

In discussing the budget-position requirements, is the BAS team

working with bureaus on how that data is currently tracked (MARS at
NOAA, Census is working to adopt the budget position module of HR
Connect)?

What will the outreach to SMEs etc. look like? interviews? table
talks? Will there be a limit on the number of stewards/SMEs/users
you'll be reaching out to?

Can you speak more to the outbound data services?

In 2022, we will be moving a new talent acquisition system. Will

there be a plan to pull in that data as well?

Are you coordinating with Enterprise Services?

Will the One Stop Shop and BI Marts have integration across the BI
Marts and One Stop Shop using a "common" identifier or Document
number?

What does Single Standardized instance mean in this context in view

of different and various data sources in addition to the 3 BAS areas.
You keep mentioning an ATO for each data source? This is not a
common process - Isn't the ATO for the EDW environment? and then
there are a combination of ISAs and control updates for significant
changes to the environment (versus a new ATO for each source)?
Each external data source would be evaluated within the context of
the standardized interface (i.e., IPSEC VPN, etc.).

NOAA provided more data sources than the few listed. How are
these accommodated? How was this "scope" vetted with NOAA /
Executives/ Decision Makers since it appears to not include critical
data sources that would be essential to support operations? I don't
believe NOAA agreed to these few data sources.

NOAA has Payroll for NOAA Corps (US Coast Guard), MARS,
Observing Systems, Goal / Programs, etc. that would need to be
included.

How will the BAS PMO ensure that all interfaced systems / all
associated objects / attributes are included in the Core Financial
System to support data reporting? Will these be included in the
EDW? It is unclear how the interfaced systems / all associated
objects / data attributes are being captured to ensure they are
included in the appropriate BOI data marts and EDW as an
integrated representation to support reporting. Please describe
when these discussions and analysis will occur?
Will requirements grooming include the integration of data
attributes / Core Financial and Acquisitions Interfaced data to ensure
reporting can be supported?

When will the EDW data model be presented to ensure that the
required data will be available / accessible in the EDW and BI Marts?

Requirements grooming doesn't appear to be integrated across all

data sources, the 3 Core BAS functions, etc.? Where does this occur
to ensure an integrated solution is implemented?

There are Bureau-specific systems required to support the Bureau's

managerial reporting. Will bureaus be able to upload this data?

Does EDW really address one-stop-shop needs of bureaus to be able

to move away from custom systems and bureaus needing to have
their own data lakes and reporting tools?
 I've heard that BAS will include development of standardized and ad
hoc reporting capability using Tableau, an analytics and visualization
tool, Won't different BI tools be needed for reporting? Are there a
list of BI applications under consideration?

Will BAS have any reporting solutions for Core Systems

(AR/AP/GL/PRISM) that capture production data on the day of
processing, or will all standardized and ad hoc reporting solutions
generate from the EDW day-old data?

What is the EBS equivalent of CBS Transaction Codes? How are the
debits/credits of a transaction in EBS derived?

BAS Projects are not synonymous with CBS projects. We are trying to
understand how cost centers of direct and indirect data can be
grouped, analyzed, and reported. Please confirm that the last
characters of the Org Code will capture what we now consider
'project-task.' If that is not the case, how will cost centers of data be
captured?

What types of obligations included in PRISM? In CBS, NIST AP must

manually key in some type of obligations that do not go through
procurement office, such as Training, miscellaneous obligations, IPA,
NIST Associates agreements. Will these types of obligations still be
keyed in manually in BAS or can they be linked with PRISM?

What kind of vendor maintenance control will BAS have? Currently,

when the procurement office cannot find a matching foreign vendor
in the vendor table, it fails to create the obligation record in C-Star.
Is there a better solution in BAS for this situation?

Should we expect the BI Marts to be created from the BAS EDW or

from the application data?

For invoices, many mail in or ask us to directly download from their

web portal. If the new e-invoicing system can be compatible, we will
have increased efficiency. Can we survey some large vendors (in
terms of volume and dollar amount) to see whether IPP is a
preferred e-invoicing system to benefit vendors and DOC?)
In some instances, we find it difficult to determine if a problem is a
risk or an issue. What should we do in this instance?

Will BAS replace MARS? If so, will BAS pull the same workforce
information from NFC? Today, MARS does not have a direct
connection to NFC (COBOL) and uses at least 2 complex FESI files to
pull data. Will you talk with the MARS team to get specific field
names to connect the data to incorporate workforce data?

When we can expect to have user test accounts access to test the
BAS/Sunflower implementation?

Will the payment processing be changed to "quantity base"

payments? In 2006, we had problems with a few contracts and Pos
being obligated in the system based on quantity. Since then, I've
never seen any obligated or no match" payments that were based on
quantity.

What is the status of the BAS ACS Crosswalk team on determining

the new BAS structure? Who from the bureaus are participating and
how are they being involved to provide input and impacts to bureau
operational business processes and changes to bureau specific
feeder systems.

Some C.Stars users are used to seeing our Business objects reports
with near real-time data display ,e.g., the Outstanding Commitments
reports. Can we expect similar reports created in BAS? Which BI tool
will create these reports, assuming reports created from the EDW
won't display near real-time data?

Regarding G-Invoicing and BAS integration,

(1) has there been collaboration between the two?
(2) How quickly after Go-Live will integration occur?
(3) What level of information will flow between the two systems?

Does the BAS Project include providing training to the Bureaus’

Power Users and General Users on the BAS EDW BI reporting
application (Tableau)?

What is the relationship between the Enterprise Data Warehouse

(EDW) and the Data Lake (into which legacy data will be migrated)?
Will it be possible to access/join both data sources in a single
Tableau query?

Will BAS be able to track work order numbers associated to project /

tasks for NIST’s OFPM (plant) operations?
Will each user have the ability to edit/update information in the
system without going through BAS to do so?
Will each user have the ability to update several leases without going
out and then back into each one, separately?
Will there be annual/semi-annual shutdowns of the system to
reconcile data/accuracy?
How will SSO work for Sunflower, if it can be accessed outside of
BAS?
Has there been any discussion of whether Sunflower Network
Discovery Tools (currently in use at several Bureaus) will be
operational under BAS?

Is there a master list of EDW report fields and canned reports that
will be available for Travel?

Will the BAS portal be internet-facing or restricted to DOC Network ?

(If internet facing, how will Single Sign On (SSO) work?)

Which continuity of operation features will be built into BAS?

Currently the NOAA C. Suite Tier 2 helpdesk has read-only access to

the C. Suite database for both custom reporting and troubleshooting
functions. Will the same kind of access be available in PRISM?

Who at DOC will approve HVA and ATO for BAS?

In the future, can the slide deck be attached to the meeting

invitation?

Are bureau reps being included in Security Sessions?

Will all CS participants be invited to the Sprint closeouts and the

follow-on Sprint Kickoffs?
Is it possible to have view access to the Risk dashboard that was
briefed?

Can you provide the Tech/Arch documents?

Will you provide an organization chart for the BAS organization?

Perhaps include BAS folks and their responsibilities.
Unable to see all of the responses for the open ended question
"which topics would you like to see in upcoming communication
events."
CORE System implementation for NIST starts Q1 FY2023 and
deployment is at the end of Q4 FY2023. During the implementation
period Q1-Q4, do we still use CBS or the new EBS application?

How is the Unique Entity Identifier (UEI) going to impact BAS vendor
table maintenance?
Will the DUNS field still be available in BAS for all legacy
transactions?
NIST currently uploads year end estimated accrual (EA) from EA
application into the CFS. Will EBS have a similar capability to upload
year-end EA transactions as one batch? Or will the EA module be an
integrated part of the EBS?

What BAS EDW fields will be available in the EDW; what access will
OFM staff have to that EDW data once deployment begins? Will
multiple users have ad hoc capabilities to create reports?

What is the CBS Budget Operating Plan (BOP) equivalent concept in

Oracle EBS?

When will NOAA have the opportunity to see EBS in a test

environment to increase our knowledge of how EBS works? What is
the time frame for this action?

Given the transition year for NIST, implementing Q1 FY23 with

deployment essentially Q1 FY24, what expectation will there be for
users to keep updated or analyze two systems simultaneously?

Will we (NOAA/NMFS) be able to see what reports are available to us

in BAS in April?

What is the plan for the existing database within the FRPM system?
Is there any plan to archive/preserve the database of this system for
future access during and/or after the transition to Sunflower?

Will all the Oracle EBS standard/seeded reports be activated for use
and will they be exportable into Excel format (i.e., without multiple
headers as with text files)?
In some of the presentations, I noticed that a VPN is being created
between the PRISM and EBS applications; what exactly does that
mean? Is this a VPN within a single hosting location or between two
different hosting locations?

If NIST Acquisition does a cross-serviced contract for a

NOAA/EDA/BIS action, how will the correct accounting get to EBS;
and vice versa, if NOAA Acquisition using PRISM does an action for a
NIST CBS bureau how will the accounting be accommodated?

Who will be trained in Dec 21 for BAS user acceptance testing? Can
bureau personnel participate in this training and the follow-on
acceptance test?

Will both applications be ATO'd along with the hosting locations?

In CBS today, we must execute SQL updates against the back-end

database several times each day to fix problems created by the
front-end software that cannot be fixed by the front-end software.
Has BAS collected these queries and the circumstances in CBS that
require their use so that BAS can prevent the need for these back-
end SQL updates in BAS?

If Census is not deploying this BAS system until FY24, is there

anything we (Census) need to be doing in the meantime?

Currently CBS has separate tables for customers and vendors. As I

understand, EBS will have one common Global data table for both
CBS tables. With all bureaus sharing the Global data, how will this be
maintained and what governance policy will be established to
reduce duplicate records?

If an additional Q&A session is needed between Sprints (prior to

May) is that a possibility?

When will we get to see demos?

Will the bureaus be able to write Tableau queries that join data from
BAS and PRISM?
Will EDW Tableau Power Users be able to write custom SQL, or will
they will be limited to dragging-and-dropping pre-designed objects?

If any of the BAS applications such as PRISM and EBS Financial

canned reports do not meet our users reporting needs, should the
Power Users be allowed to develop custom real-time operational
reports from the applications databases?

Will the legacy NIST CBS and CSTARS data migrated into the BAS
Data Lake allow NIST to meet all NARA retention policies for financial
records?

Can NIST put content on the BAS Portal for NIST and its customer
bureaus to access?

Are you aware of any discussion at DOC regarding incorporating a

bankcard component into BAS? Perhaps as a component of Prism? 

Will any lessons learned be documented from Real Property so they

can be applied to future deployments?

Will the BAS Technical Architecture be provided to the Bureaus for

review and comment? 

With EDW being delivered, when will Bureaus be given access to that
environment?

What is the link to the Town Hall slide decks?

Can you define the BAS website? Is it considered DOC or CSC?

On the BAS website, can you make the High-Level Program

Schedule easier to find? I could not find it by searching. I had to
resort to finding it in a slide deck attached to a meeting I attended.

Can you send us a list of the questions that you have already
captured for the next BAS Q&A, or is that on the BAS Webpage?

Can BAS discuss Internal Use Software (IUS)?

Are there any updates regarding Summary Level Transfer (SLT)?

Will you be developing a directory of stakeholders - property,
finance etc.)? I get a vast number of emails and get overwhelmed as
most do not pertain to my area.

Will you share the implementation plan?

When will the National Finance Center (NFC) delay be addressed?

For BAS, will commitment accounting be used only for PRISM

transactions or will it be used more broadly such as for Grants, Travel
etc.?

Will the responses provided to these questions be provided in

writing?
Can you please elaborate on adding Content to the BAS Portal.
Would this include data into Oracle Db tables?
During which sprint will commitment accounting be evaluated for
Bankcard and Grants?
Who decides who will be classified as a Power User? What are the
qualifications to become a Power User? Since Power Users will not
be granted access to EDW tables, how will the inquiries be
written/committed for ad hoc reports?

So far the previous BAS Program Common Solution sessions were

very helpful. Could the future sessions be recorded and shared with
us?

Will the data for Travel and Purchase Cards be real-time?

I suggest putting a link on the main page of the DOC BAS page that
takes you to a high level project timeline. I have to dig through too
many documents to find the overview timeline of the project. It
takes three clicks to see it. Such a fundamental document should be
a single-click option.

NIST has over 130 users who can create ad hoc reports against our
financial data. Do you see granting that many power users?

Will current access to individual server (e.g., CBS, Sunflower etc.)

remain or will all data need to be accessed via EDW?
I just heard you say there may be the ability for users to write ad hoc
reports in EBS? Is that accurate?

Will there be a full test/dev instance that the bureaus can use to test
out API interfaces for bureau individual systems?

Does Tableau  allow for the report output to be a variety of formats (

e.g. CSV, EXCEL, WORD, PDF etc.)?

Will EDW have a capability of ad hoc query building and reporting

available for Bureaus/Line Offices?

For future Q&As, can answers to pre-submitted questions be

displayed in writing on the presented slides in addition to the
relative SME answering verbally?

Is commitment accounting included in EDW reports?

If SQL is allowed for power users, will there be a data dictionary that
provide table name structure and file names etc.?

Are Monthly Labor estimates creating commitment or obligation?

Does Tableau have a dynamic user prompt feature?  Does it also

have a recurring scheduling feature as well?

What are the specific configurations that will be completed for the
GJ process?

Since journal entries are batch oriented, how can we be sure the
information that we see is the most current/up to date?
How are batch/bulk approvals completed?
Can auto posting be used to queue up JVs for year end processing
purposes?
Can posting be both automatic and manual or is it solely one or the
other?
What happens if a bureau disagrees with a configuration validation?
What are the next steps?
Can there be additional adjustments types - Refund, Write-offs, Re-
open, Refer, Waive, Cancel, Dispute, Change MDL included in EBS?
When can we discuss having these included?

For the Line adjustments in EBS, can you go from "1 ACS to multiple
MDLs (different ACS)" or "Multiple MDLs (different ACS) to 1 MDL
(ACS)"? We understand the dollars for the line must be exactly equal
after the adjustment.

Currently NOAA does not use/require a second level approver to

approve adjustments in CBS. Is this a required process in EBS? Can
EBS be configured to not require a second level approver? Can it be
configured for only high threshold amounts?

Can you please provide a list of all the Adjustment Reasons in EBS?

Who/what role will be allowed to make changes to the Adjustment

description?

When processing adjustments, is there functionality in EBS to allow

adjustment limits be set up based on role? If we have to add
adjustment levels per user, there will be a significant ongoing
maintenance effort. In CBS, there are no requirements for
adjustment limits or adjustment approvals.

If the adjustment limits have to be set up by user rather than by role,

who will be responsible for adding the adjustment limits to users
(whether they are existing users or new users)?
If the adjustment reason of "waive" is used how would we waive
overhead charges and rent? We would like to understand this
process better. (For example, NOAA Line Office creates a bill for
$1000 and charges $100 for rent. The rent is waived for customers.
Line Offices have FMCs and the cost is incurred from the FMCs on
Object Classes. How would rent be waived on the overall bill?)
Currently transactions and adjustments come through ARSI for the
Seafood Inspection program. When does the BAS Team plan to look
at the Accounts Receivable Standard Interface (ARSI)
code/processes?

Fisheries Loans uses the AR003 screen as a debit memo. Is there a

way to add an adjustment to a loan? Does adjustment mean just
correction or is it applicable to loans as well?

Will there be an RA (or equivalent) module or capability?

How will GSA rent and overhead waivers, for reimbursable

agreements be handled?

We currently use AR004 for bill adjustments and AR003 for

receivable adjustments will there be an accommodation for these?
We have several different adjustment types that we need in the
system i.e.(credit and debit memo adjustments). Will these be
available in EBS?

Please clarify which are credit and debit memos and can we add
adjustment types for items such as credit and debit memos?

Are batch (bulk) adjustments possible? Are there other ways besides
running a report to get a list of adjustments? Currently we have
more flexibility via queries etc. Are we limited to just the ACS versus
the project/task code level?

When waivers are processed, the waivers move the cost from a
reimbursable agreement project to a direct project. Is this
considered an adjustment? How will waivers be processed in BAS?

What is the process to include additional NOAA adjustment types?

Are these for each OU or applicable to the agency?

Please also provide clarification on the process that will be used to

include additional adjustment types.

What are the codes for the adjustment types? Can a user modify
these?

"Type" is referenced multiple times. Does this apply to all

adjustment types?

NOAA uses DLCAs to process labor adjustments. Is there equivalent

functionality in EBS? Are all labor adjustments done on a project
costing basis? Can you please clarify if adjustments can be made to
an invoice or a line? Can adjustments be made if a cost is not tied to
a specific project code?

Where and how are approval limits set up? Will OUs be able to have
their own approval limits? Is it hierarchal? Could you please also
provide specifics as it relates to thresholds, limits, etc.?

What is the process to approve additional adjustment reasons? How

do we restrict users from creating reasons?

Can you provide clarification on who has control over reasons? Is it

SYSADMIN or another user?
How is the process different between using the screens (individually)
versus uploading a batch? Is the approval process handled
differently? Please provide additional clarification and details on the
automatic approval process.

1) Can you explain in more detail the difference between Standard

and No Remittance?

2) In this context what is meant by cleared by the bank?

3)What are the sources of the receivable? We have more than just
pay.gov.

4)How are CIR and OTC Net accommodated?

5)Does EBS have similar functionality to OTC Net or will we continue

to use OTC Net?

1) Can you describe the deposit screen and process for assigning the
receipt for the deposit ticket?

2) We need to understand the batch/bulk screens and how they will

work.

Is there an option, for the bureaus, to identify a customer number to

avoid unidentified receipts?

How does the screenshot match up to the bill? Does it need to

match a bill? If it does not match a bill can it be reconciled?

Can you provide more context on the current AR009?

Can you describe the relation to the lock box process?

How will the assignment of deposit tickets to the receipt log be

handled?

Will there be a standard automated AR interface? for example

Seafood Inspection

What is the equivalent functionality for this screen in CBS?

When can we expect the separate session you mentioned on batch

remittance and how receipts are tied to a deposit?

Does a receipt have to be applied to a bill or can it stay in unapplied

until more research is completed?
What is the equivalent functionality for this screen in CBS?

If this is an interface how does the data mapping occur?

Once receivables are entered is there a way to adjust it?

How does EBS handle interest paid from external sources i.e.
Treasury

How can we track more than 7 buckets to accommodate Treasury

requirements?

There are two parts of automation for NOAA. The creation of the
receivable is separate from application of the receivable. Did BAS
mean the automation method was applicable to the creation of the
receivable from Seafood Inspection or the application of the
receivable that comes in from CIR?

What is the name of the program that allows the communication

between AR and AP?

Is unidentified cash considered a miscellaneous receipt?

What scenario would require the use of unidentified cash?

How is AP used to send back unidentified cash?

When can we expect the separate session you mentioned on how to

tie a receipt to a deposit?

How are tax transactions and postings (e.g., PCS(relocation)

transactions) handled in the Payments Module to ensure they are
reportable for Treasury?
For annual 1099 reporting, how does EBS identify what is reportable
and how are 1099s processed? How will the 1099s be provided to
recipients?
Some screens are for the user and some seem to be for the system
administrator? Could you please identify which screens are for which
user?
Since the EBS process is so different from the current one, would you
please provide us some written details of the payment process in
EBS? Will this process now be manual? We'd like to have a concrete
understanding in order to provide decisions necessary during the
next AP Payments meeting.

Could you please provide some written detail concerning the

following: scheduling the payment process and how the payments
are batched?

Can PAM handle multiple formats (e.g., PPD or CCD) in the same file?

Can you please provide us a description of each of the potential

methods to send disbursements to Treasury?

Will Connect Direct be used for Treasury Payments?

Which format allows the best / most flexible remittance advice of

the formats shown?

If CTX is a better ACH format to use for certain transactions, what

transaction types would that be and how can we take advantage of
it?
Will the payment terms be based on the contract level? Do they
have to be set within EBS?
Will the user be entering all the Payment terms or will this be
managed by a System Administrator?

For matching documents coming from PRISM will the payment terms
flow into EBS from PRISM? Can the payment terms be
adjusted/overridden once an invoice is received or will the payment
terms always be defaulted in EBS? If this is not something in PRISM
(e.g. discount terms) but they are offered on the invoice is there a
way to put them in EBS and does BAS intend to use those
capabilities?

Will all interest penalties be set as a default of Net 30 if subject to

Prompt Pay?
Will Net Days be a required field in PRISM on a contract? If the plan
is to use e-invoicing, will PRISM be able to ensure the prompt
payment rules will be embedded in PRISM and be consistent with
EBS?

There are payment terms on the vendor in PM002 - will they come
over from SAM and flow into EBS? Is this set from SAM.gov or is a
user setting it based on some criteria. What is the criteria?
Does the system distinguish small businesses?
Does EBS have the ability to do the 1099 reporting or do
users/recipients have to get the data and pull it down?
Will EBS keep interest payment effective date historical data?
(screen shot to right).
What date does EBS use to start the clock for calculating interest? It
appears that we're in disagreement concerning PPA. According to
OMB 5 CFR Part 1315, the due date for interest is calculated
beginning 30 days after the latter of the 1) Invoice Date, 2) Invoice
Received Date, or 3) Goods/Services Acceptance Date. Does EBS
calculate the Due Date using the latter of the above dates? Will an
example be demonstrated?

What do users have to set all to meet all the requirements of prompt
pay within EBS?
There are many invoices where Prompt Pay does not apply to a
vendor. How does Oracle EBS account for this?
Can you setup a recur for a matched document?

Will all transactions on the recurring invoices screen be "posted as

approved" where the payment goes out every month? Or is there an
option to post recurring payments as "not approved" (e.g. Utility
payments)?

Could you please explain what dates go into the First and Next Day
fields on the recurring invoice screens? Sometimes we have
payments that would need to be paid monthly but other times we
make payments just once per year,, quarterly as well as on a very
specific date within a year.

Can recurring invoices be set up for "matched documents" (e.g.,

monthly fixed maintenance fees, leases)? How will this process work
in EBS?

How would utilities be handled if they are generated and still need to
be approved?

For the Terms Data Basis, what is System defined as?

How does interest invoices get tied into obligation? By selecting the
"create interest invoices", will there be an impact on funds balances?
Does this reduce the obligation that is recorded?

How is interest posted? Where does it get tied to in EBS? Is there a

way where interest penalties cannot hit certain Fund Values (e.g.,
cannot hit a Labor Fund Value)?
Does EBS automatically account for Federal Holidays and weekends
and is this configurable in EBS (NOAA follows the Treasury PAM
guidelines)? Will you use lag days or will there be a calendar in EBS
to handle this process?

How will EBS configure payment tolerances? Which module is it

configured in and how will tolerances be used in EBS?

How will the "do not pay" codes apply to the payment process?
Since all bureaus will use EBS, will suppliers be set up for each
bureau or one supplier set up for all bureaus? If there is just one
supplier set up for all of Commerce and the supplier is identified as
"do not pay" for one specific bureau how will that not impact all
other bureaus?

What will be the process for reconciling suppliers against the DNP
list? Will each bureau conduct the reconciliation or will someone at
DOC handle this process?
Would you please provide details of the Do Not Pay process in EBS
and how it will work
Where are the "Do Not Pay" reason codes applied in EBS? Is it during
the validation check at the beginning of invoice processing or after
payment is sent to PAM? Is this managed by the system or by the
user?
What are the implications of assigning a DNP reason code to a
supplier?

It was mentioned during the meeting that a data call came out for
Do Not Pay? Did this go to the bureaus and if so who responded?

How will the data files for batch processes like SP3, Telecom and UPS
invoices be handled in EBS?

Will each bureau be responsible for disbursements (and have their

own certifying official) or will the disbursement process be handled
centrally at DOC since all bureaus will be using one system?

When moving to BAS, will each bureau have a separate payment file
to Treasury or will there be one for NOAA, BIS and EDA?

What controls, reports or tools does EBS have for review to prevent
the payments from failing and identifying the problem?
If you have one bad transaction (e.g., character not allowed in a
field, mismatched BETC and dollar amount), are there controls in EBS
to prevent the disbursement file from 'bombing" or are their reports
that allow you to review the disbursement transactions before they
go out?

For non disbursement transactions, how will the payments or cash

be posted?

Will an EBS user be able to create records for International

Suppliers? Add their international banking information (SWIFT,
IBAN, etc.)? If an International Supplier registers in SAM.gov, what
information will an EBS user be able to edit? Can their international
banking be added (can't be added by the Supplier in SAM.gov)?

Does EBS track the historical exchange rate for foreign vendors?
Because EBS can handle foreign payments how is the exchange rate
determined? Is the foreign payment when it is processed and
approved or when it is disbursed? In CBS, for payments is it a manual
process to put in the actual amount that is disbursed?

While we understand the current plan is to use USD in EBS, is

Foreign Currency (paying in or converting to) out of scope for the
project? It is our understanding that Treasury has a 440 file process
for International Payments. Will that be supported?

Anything that has to be handled outside of the system and would

maybe not be integrated (e.g., 1099 forms electronically delivered to
recipients or maybe foreign payments, etc.) - will DOC provide the
standardized process or tool or will the bureau choose their own
solution?

How will EBS reconcile what was paid by Treasury? Is it a manual

process or automated?
Is the submit payment process request roughly analogous to PM
102/103 today?

Currently, AP Technicians are not allowed to Approve invoices for

payment during the disbursement process. This ensures that all
payments reviewed are disbursed and those that haven't been
reviewed won't be disbursed. How does EBS handle payments that
are approved during the disbursement/payment process?

Is there a summary of payments based on their Template that is

broken down by TAS/BETC (e.g. PM103 report output)?

Who determines the format (DOC, the Bureaus, Treasury) or is it

based on the vendor type (corporate, individual, etc.)?

Can you discuss what interfaces will be covered in BAS?

When will we cover the other AP Payments such as ASAP Payments

for Grants, EFT Payments for Grants, Foreign Payments, IPACS etc.?
For SP3 payments, DOC tailored APSI so that the description
information is loaded into a Notes field for the invoice so Sunflower
can extract data related to all the 3100 Object Classes as an
example. How does BAS intend to incorporate this information?

What does the dashed line from DNP to BAS mean? Currently there
is no automated interface between DNP and BAS (batch job and put
on server and is sent in conjunction to Grants Online DNP data).

Why is the dashed line not bi-directional between DNP and BAS?

Can you provide an all inclusive list of all interfaces?

We use more than one Treasury Payment System today. In addition
to PAM, we also use ITS, IPACS, ASAP etc. Will these systems also be
included in the BAS Solution?

There is more data than just SAM that feeds into the Payment
process. There is also a feed that we receive from banks - Financial
Organization Master File (FOMF)/ABA File (Bank Routing #). Will this
be included as a feed into EBS?

Is the Financial Organization Master File (FOMF) happy path?

The process flow appears to still be very high-level. Will there be

detailed process flows developed for review in the near future?

Will EBS be able to accommodate Wire Transfers?

What are the finalized Payment Reason Codes configuration? Will a

list of the Payment Reason Codes be provided to ensure that the
configuration meets our needs?
EBS is missing the Treasury Rate as the offered discount which can
result in 15 day, 20 day (faster payment terms). Will these be
included in the configuration.
Will a bureau be able to add additional Payment Terms? What
happens if we receive an invoice with payment terms not on this
slide?
Current Value of Funds Rates come in once per year (January 1st)
from Treasury. Will this be accommodated in EBS?

Can we override the overall Discount rates in EBS?

What is the mechanism within EBS to ensure that Accounting

Operations can make the appropriate discount term entries at the
time they are processing an individual invoice?
Are the payment file types for all Payments or just PAM and DNP?

When does the BAS Team plan to look at the APSI code/processes?

Can standard pay terms be overridden?

If an invoice has a different discount on it, will we be able to add that

to the payment?

If we do not have an invoice received date, what date do we use in

EBS?

Will all interest penalties be set as a default of Net 30 if an invoice is

subject to Prompt Pay?
We also have a late reason codes for DOC reporting purposes. Is
there a field to capture that information?

Can the recur be set up to not automatically approve and disburse?

Is there a function in EBS similar to the CBS PM201 where existing

recurring payments are generated and posted in batches regardless
of the frequency or do we have to go into each Recurring Payment
individually in EBS to have them posted?

For the increase, can that be set as a dollar amount at a certain date
instead of monthly/yearly percentage?

Can we get a list of what errors EBS looks for before the payment
batch is disbursed?

Will templates need to set up for each ALC?

Will certifying officials need to go into SPS and certify disbursements
at Treasury?

How will EBS accommodate foreign payments through Treasury's ITS

and SPS systems? Treasury has a 440 file process for foreign
payments. Will that process be available in EBS?

What commitments will be included in BAS?

How might a bureau process multiple ALCs during a payment run?

Is there bureau specific controls as to when its payment run can be

processed? (i.e. Can NIST initiate their payment run at a different
time than NOAA and Census?)

What AP reports are available in EBS to validate/pre-audit invoice

payments before they released to the PAM schedule?

What would be the process for "fixing" a payment file that fails edits
at PAM? How do you back the paid invoices out of EBS so you can fix
the issue?

Will NIST have to kick off the payment run process for each of the
bureaus we cross service (7 other bureaus) or is there a feature to
include all of the bureaus for a particular days payment run?
Not all vendors with Payment terms of NET 30 Days offer a discount
or may offer different discounts 1/10 vs 1/15, etc. Can this be
handled in BAS?
Will EBS allow for the proper pre-payment to be recorded rather
than immediately expensing the entry?

Will the recording of estimated accruals be contained in the EBS

module or will it be an additional module within BAS?

What does TAS mean in this context (Task order, Treasury Account
Symbol)? Does TAS really refer to an ACS level accounting code?

What is the interface between G-Invoicing and EBS specifically,

relative the reimbursable agreements and IAA? What modules
within EBS will the data from GT&C reside?
How does the data crosswalk from G-Invoicing to EBS? For example,
where does the reimbursable data go when it is interfaced, to the
Projects module?
Will G-invoicing create and generate the 7600A forms to and from
EBS depending on who provides the service?
Are EBS supplier records and payment terms interfaced with the G-
Invoicing? For instance do new IAAs create the supplier agreements
and the terms, or is it still a manual process?
Will the TP Main information for non DOC federal agencies be
interfaced to EBS? I assume EBS will have the TP Main in EBS for DOC
agencies.

Will the EDW Team be addressing how the underlying data is joined
together and the transactional lifecycle reporting (i.e. commitment
to final closeout)? When will the bureaus be engaged to validate the
requirements for this?

What attributes/flex fields will be set up/configured in EBS and will

they get embedded in existing operational reports in EBS? If these
fields are not embedded in operational EBS reports will users be able
to get the attribute/flex field data in the EDW for reporting
purposes?

Could the BAS Team please provide a listing of all the available EBS
reports, a description of the reports and a sample output with real
transactional data for each report as well as the data elements, sort
orders and selection criteria per report?

For all components (i.e. sources of data such as Core Apps and any
other data sources feeding into the EDW (e.g., Grants Online, PRISM)
within the EDW, what is the refresh cycle? When will the data be
refreshed? Will this be refreshed in batches or in real time?
What will be the process to ensure all data calls are incorporated
into the BAS solution and can be supported by either EBS or EDW
reports?

Can each of the Category of Reports available in Oracle be run by the

Fund Value parameter?
How will EBS AR data get tied to NOAA supported systems like
Seafood Inspection (SISP) which generates a significant amount of
receivables for our bureau?
Do the AR Reports in EBS also accommodate Reimbursable
Agreements?

Is Reimbursable Agreement Number an additional parameter for

running AR reports in EBS?

Is Accounts Receivable Number an additional parameter for running

AR reports in EBS?
Is Project Code an additional parameter for running AR and Budget
reports in EBS? How does the Project Code get included in reports if
it is in a different EBS Module? Which reports in EBS can be run by a
Project Code parameter?
Is Bureau an additional parameter for running AR reports in EBS?

Is Task an additional parameter for running AR reports in EBS?

Is Deposit Ticket Number (found on CBS AR104 report) an additional

parameter for running AR reports in EBS?
Will the Common Report Parameters be included in every report or
just some of the AR reports in EBS?
Will Project Codes be mapped from CBS and if so how will they be
reported on?
Could you please provide a sample output with transactional data for
all of the Top 10 AR Reports?

What reports are available in EBS to reconcile deposits and

payments with Treasury's CARS system?

Is it possible to create an Aging Report in EBS with more than 7

buckets?
Does EBS have the ability to customize TROR reports? If not, would
this be accommodated by the EDW?

Do the EBS reports come out of transaction tables, subledger or the

general ledger? Will a user be looking at the most up to date
information when running a report? If something has or has not
been posted to the general ledger does it change what you see in
the reports?
NOAA currently has 143 Quick Reports in CBS which are used
frequently and can be provided to the BAS Team. Will these Quick
Reports be mapped back to EBS Operational reports and how will
they be accommodated?

Can you provide a list of the reports which have the output format
of Excel?

How will a bureau pull reporting data for TROR in EBS?

Can Organization Code be used to generate reports in EBS?

How does commitment accounting work in EBS (e.g. Grants, Travel)?

If this information will not come through the PRISM interface to EBS
then how will this work for Reporting? Will commitments be
accommodated in the EBS or will it occur in EDW?

Can you please provide a list of all the parking lot items by
Workstream that still need to be discussed or have been deferred?

What is the ALC code(s) going to be for BAS? NIST currently has one
ALC which we use for all of our serviced bureaus reporting

Can you describe EBS's project/task code functionality to better

understand any upstream implications to the ACS funding structure,
GJ entry, and Budget Operating Plan entry in EBS.
What capabilities are there in EBS that will allow us to manage the
fund codes separately as they are today?

Are the fund code correct?

Does the program code structure align to the NIST budget request?
Can you confirm the Department program structure?
NIST is required to track several other elements, which are currently
tracked at the project level in CFS, i.e. NSF, Goal code, Budget
Initiative code. Assuming these are tracked at the project level, and
they're required for reporting, how do we confirm all transactions in
EBS will have a project code (or equivalent, e.g. event, task)?

Is there a follow-up meeting planned for the BAS team, NIST, and
Department Budget to clarify the BAS program code structure?

Are the NIST Org codes updated?

Are the ITA legacy codes updated?

Can budgets (like CBS's FM066 BOPs) be established to the higher

level Orgs, like to Org level 3 for NIST, and to Org level 6 or ITA?

If NOAA establishes funds control to the Fund, Program, and part of

the Org code, will BAS be able to accommodate both scenarios?

Can you describe NIST "internal" object class codes (outside the
OMB defined range)?

Can you discuss NIST's Object Class 11-13, leave charge?

Can you discuss the NIST Object 12-09 benefits surcharge?
Can you describe Object class codes and standardize DoC wide?

Is the OMB standard 3 or 4 digits?

Is there a sample (nearly complete) 7-digit BAS OC structure that the

bureaus can use to attempt to crosswalk our existing OC code
structures?

When will NIST sub accounts be factored into the BAS migration?

When querying in EBS for a multi year ACS, how will we be able to
pull data for multiple fiscal years if the ACS string will have different
values than in CBS?
How are we going to standardize internal sub accounts? What will
the process be and in what Sprint will we standardize?
Since the USSGL is part of the BAS ACS that Posts to GL, will
reporting strip out the additional rows showing the USSGL accounts
with the rest of the ACS and represent the net effect of the
Transaction?

When can we work with the BAS team to provide input from the
bureaus on USSGL sub accounts that are not USSGL specific (e.g.,
memo accounts for tracking money)? What will be the process to
reconcile the Bureau specific sub accounts to ensure they are
accommodated and if they cannot be accommodated can other
attributes be used elsewhere in EBS?

How can budgets be established at different levels of the

Organization?
Will all components (fund, program, org, obj class, etc.) of the ACS be
a single data set that is shared among all bureaus, or will there be
certain ACS values that will be controlled specifically by each
bureau?

For the 3 positions of the Object Class that are marked with an "X" in
the
The Crosswalk,
Object Class will the
will 3 positions
impact be the
not only bureau specific
financial or shared
system but also
across all of DOC?
PRISM, Sunflower, WebTA etc. Given the use of the Object Class 4
within NOAA for things like Fee for Service, Surcharges, tracking of
funds management etc., if EBS has additional character spaces for
the Object class, why can that additional space not be used to
accommodate bureau requirements? Are we going to be limited to
just 7 digits, or are we going to be able to have additional flexibility
Will there
beyond be a crosswalk from CBS within EBS so that bureaus do not
that?
lose the ability to analyze data (e.g. obligation reconciliation for
NESDIS and NASA) if we cannot convert the data we have currently
in CBS (all Object Class positions)?

If policies must be modified and revised to accommodate

standardization within EBS, who will be responsible for the policy
updates? Will it be up to the bureaus to make these changes?
(asking so we understand resource needs and can plan work with a
considerable amount of time to make adjustments)
How will reimbursables work in EBS for funds control?
When will BAS discuss the additional attributes required at the fund
and program levels?

How will BAS process reports at the cohort level for appropriation
input?

The reprogramming package goes into the apportionment manager

but we do not put it in the financial system.

Programs are usually broken out by category A or B not at the fund

level. To what levels can EBS specify these categories?
Can you describe commitment accounting, would we be able to do a
full year labor without it hitting at once?

If project is not part of the ACS how can funds control be done
around it?

How can we be doing budget entry CVS on 3/25 if we aren't getting

the information on how projects will work until 3/31?

Will there be additional discussions on this topic to get to a DOC

standard? How will bureaus be able to agree to a configuration by
March 25th if there is not more discussion before then?
Is there an EBS equivalent to the FM061 Program Authority Screen in
CBS?

How will BAS address mandatory and discretionary within the fund
value?

Please confirm that the levels in which we execute our budget can
be different then our level of funds control.
Can the funds control standardization vary between direct and
reimbursable fund types?
Can Census ask to raise funds control back to the standard/fund
code level in the same year?
Is there any room for webADIs or any other automation in order to
record the allotment entries?
How are labor and cost allocation entries handled if funds are
unavailable?
If Census wanted to (a) execute our budget or (b) establish funds
control at a program2 or organization code 2 level, how can this be
accommodated?

There was reference to an internal BAS fund value that could be

used to separate supplemental funding from the regular
appropriation. Can we have more discussion on this topic?

Can EBS be configured to allow funds control at multiple levels as it

is in CFS today?
Can you describe the EBS Program and Org Structure?

Is there functionality in BAS EBS to move funds from one org to

another? If so, does this need to be done at the allotment level?
How is supplemental funding is handled in EBS?

Is there a functionality in EBS to upload budget entries? In times

past, NIST has uploaded some BOPs?

The BAS Funds Control Data Call overlooked NTIS (on NIST's end) -
can this be incorporated?

At what level of BAS Program Code is this being proposed and what
are the implications to proper reporting if all BAS bureaus are not
consistent in their set up? If this value is moved down from the Fund
Code level to the BAS Program Code level, how will Commerce
report to Treasury on these GTAS values?

How will proper transaction posting and reporting be

accommodated when identical Fund values may contain both
discretionary and mandatory funding? Please provide detailed
examples of how this would be expected to work in BAS.

How does BAS propose to track and report on these types of

supplemental funding within the context of the proposed BAS Fund
Value?

Can you provide clarification on what is meant by “further analysis

from Bureaus and provide feedback to BAS team”? What is the
timeframe the BAS team expects this analysis to occur?

Is the intention of the BAS Program Code Structure to embed in the

additional segments all the additional crosswalk information from
the existing CBS Program Codes (e.g., BAS Program Code Segment 5
and 6 – is this where each bureau would incorporate specifics from
their equivalent CBS Program Codes?)?

What Congressional/OMB notification will be required, if at all, for

changing bureau PPA structures to BAS Program structures?

Can you explain the CBS Fund Code and how the specificity of a CBS
Fund Code can be the source for the BAS Fund Value?

How do you assign BFY for X year money? Is it the year it is

appropriated in or the current year?
Is there a need to distinguish in the Program Structure mandatory or
discretionary accounts and how would this be accommodated in the
BAS system?
Can you explain the CBS Program 1-4 Codes and how the BAS
Program Code and how it is mapped to the BAS Program code?
Could you please provide an Overview of the latest entire ACS
structure?

In CBS there is implied hierarchy (e.g., Program code 1-4) where an

Program Code can belong to one and only Fund Code. What is the
hierarchy and how is it mapped? In BAS it appears there is only one
Program Code with 12 characters. Does this imply that each Program
Code is the PPA Level?

Can there be a working session on the Fund Value attributes to

ensure financial reporting can occur in the BAS system?

Can there be a working session on the Program Code to define the

program code attributes to ensure financial reporting can occur in
the BAS system?
Can there by a working session on the Project Code to define the
project code attributes to ensure financial reporting can occur in the
BAS system?
Will project code get written to trial as part of the transaction if it is
not part of the ACS?
Will the new ACS segments be available in the CWT E2 system so the
transactions can be interfaced into the new BAS system? Assume
that there would need to be two E2 versions since NIST and Census
will need the CBS ACCS.

There have been multiple definitions provided for BFY. These do not
appear to allow for proper reporting of when funds are obligated.
Please clarify how BFY addresses this?
EDA has internal requirements for using prior year fund, will BAS
automatically use reapportioned funds?

There are many attributes from the CBS Fund Code when translated
to the BAS Fund Value that are needed for reporting. Credit reform
loans broken out by cohort year is an example of this and we need to
understand how they will specifically be addressed in BAS to ensure
they can be reported on?

Today in CBS we use separate Fund Codes for supplemental vs.

direct funding as a way for NOAA Line Office/FMCs to segment off
what activities funds should be used for so that we comply with
Congressional intent for those supplemental funds. Can you explain
the BAS Fund Value and how this would be accommodated?

How will internal Fund Codes be structured in BAS (e.g. to support

the surcharge process)?
What is the purpose of including all the additional attributes in the
BAS Fund Value if they are stored separately as part of the Treasury
Symbol setup? Since many of these additional attributes can be
captured somewhere else (e.g., Category) why include them in the
BAS Fund Value? Could BAS use those additional positions in the BAS
Fund Value for something more meaningful that cannot be tracked
or stored elsewhere (e.g., Supplemental Funding)?

In the existing structure, how would we accommodate multiple

funds that have the same direct/reimbursable or apportionment
category settings? It would seem that we could have multiple funds
with these attributes.
Will a User have to enter the whole BAS ACS Fund Value, or just an
abbreviated version like in CBS?
Could we use the descriptive flex fields to add additional attributes
to the fund set up?
What is the process to create additional Fund Attributes to support
mandatory reporting requirements? How will these additional Fund
attributes be identified and tracked?
How will a trial balance be generated by the attributes for DEFC? Will
there be specific transactions that hit one attribute vs. another
attribute in the same value?
Will there be a process to delineate how to separate out the DEFC
Codes or any other similar attributes? Will there be a standardized
approach?
Will users be required to identify the BFY for funds that have
carryover? How will the user know which BFY to use to get an
obligation through the system if there is carryover from no year and
multi year funds?

What will be the BFY for Internal Funds and their associated
obligations?

When receiving new X year funding, are we to put XX in the BPOA in

the year it is created? Does that implies that is could be used in any
year?
Will BFY be an available field within commitment accounting (e.g.,
acquisitions such as grants)?
When obligating prior-year deobligations, will the BFY keep the initial
year of the funding source?
If you have a recovery for 2020 money and gets reapportioned will
that take on 2021 BFY?

During the recovery process, if a grant is awarded using funds from

multiple BFYs and then a portion of the funding is deobligated, how
do we determine which BFY funds were deobligated? (EDA)
How will the original BFY be determined when available balances are
moved to BAS?
Since EDA’s no-year funding is not BFY specific or limited, what is the
purpose in trying to track it? Will the BFY be a required field or
optional?

Would surcharges need to be changed or only run on current FCFY?

What constitutes the PPA Level in the BAS ACS?

Is the Program code defined within the context of a Fund?

What will be the DOC approval process/plan if a bureau would want

to renumerate program codes?

With the change of the Org Codes, will there need to be a new
upload to HR Connect? And how will that work?

Can you describe the connection between DEFC and Fund Codes?

Can you describe the difference between the mandatory and

discretionary attribute of Fund?
Will there be a further discussion coming up about the values in the
GL013 (Fund Code setup screen in the current CBS Production
environment)?

Can you give a more in depth insight on fund codes?

Can you describe the issue where the ending fund date changes after
the start of the year?

Can you describe the EBS's project/task code functionality to better

understand any upstream implications to the ACS funding structure?

What capabilities are there in EBS that will allow us to manage the
fund codes separately as they are today?

Can you describe the coding methodology?

Can you describe the coding methodology and how it intertwines
with the DOC and bureau level requirements?

Can you confirm the Department program structure?

Assuming these are tracked at the project level, and they're required
for reporting, how do we confirm all transactions in EBS will have a
project code (or equivalent, e.g. event, task)?

Is there a follow-up meeting planned for the BAS team, NIST, and
Department Budget to clarify the BAS program code structure?

How many approvals can each bureau have?

Can manual reversals be processed if autoreversals are not agreed

upon being set up in BAS?

There was discussion around DOC bureaus agreeing on the auto

reversal capability for the accrual category. Census currently record
accruals for FECA in the journal voucher module. Is this considered a
manual journal entry or will that be part of the accrual module in
BAS?

When does the BAS team intend to present SLTs, DLAs, and DLCAs?

How will BAS be able to trace these JVs back to a document or line
item level versus just at the ACS level?

Is there a way to use a flex field to gain the specificity to gain access
to a line item or document number?

Is there a way to check on the manual JVs to ensure they are USSGL
compliant (i.e. ensuring we don't charge a credit to a proprietary
account and a debit to a budget account)?

Please provide the specific controls invoke when a manual GJ is

entered to comply with USSGL?

Can you provide additional detail on the Standard operational

reports, because if there is not sufficient detail we will need to put in
additional EDW requests?

Besides funds control are there other controls available to monitor

the changes being made? (i.e. reprogramming funds)
Can we set up reversals in advance?

When we post labor estimates Reversal GJs are automatically

created for later posting. How will BAS handle this?

Can you go into greater detail with JV configuration?

In CBS, AP clean up GJs are done the ACCS detailed level. They are
currently completed manually in CBS and done frequently. How will
this be handled in BAS?

Currently in CBS, if over/under does not balance, FRD enters a GJ to

get into balance at a fund code level. How will BAS handle this?

Can the Supervisor enter JVs and also approve JVs?

Are the approval thresholds set by bureaus?

When JVs are submitted for approval is there a screen and email
notification?
What are the line numbers?
When approving JVs, what supporting documentation is there in
EBS?
Can you provide examples of JV approvals and reversals?

Can you provide examples of JV entry by GL account and by

transaction code (or EBS equivalent)?

Can you provide more information on the types of JVs, (manual vs

accrual, and auto-reversal implications)?

Can you provide additional demos of the WenADI functionality?

Is there a billion $ JV entry capability?

Is there a EBS subledger module to record investments?

Are there any real time reports which can be run to view JV entry
details, including capability to run for a specific JV?

Currently journal entries (JVs) are entered for budgetary funding at

the start of the fiscal year due to the FM06x modules cannot be
utilized until the fiscal year ending has it's close process completed
(Stage 3). Will these entries still be needed under BAS or can the
funding be entered into the Budget module at the start of the fiscal
year?
How will BAS ensure that no improper ACS combinations will be
entered for budget transactions?

Is BFY the same as the FCFY?

Will the BFY ever extend past the ending Period of Availability?
Reimbursable Agreement with DOE for 18 months (7/1/2020,
12/2021) – What would be the BFY, FY and FCFY?
If BFY in Oracle EBS and FCFY in CBS turn out to not be equivalent,
can there be an additional field added in EBS for FCFY?

How will you know if a Fund Code is used for a NIST Bureau vs a
NOAA Bureaus?

Will there be checks on whether a Fund Code, BFY, Org Code, USSGL
are valid (not just 0 filled)? Can we expand upon the CVRs to not just
check for 0 filled values?
How will the carryover process work in Oracle EBS?

Will there be other cross validation rules that check whether the
value entered is valid?

What will the future accounting streams be in the BAS system?

Will the ACS include project codes and task codes?

How will Project and Task Code be handled in Oracle EBS?

Will bureaus be allowed to create their own CVRs for our

Project/Tasks if the Projects module doesn't drive the accounting?

Will users have to select the correct USSGL?

Are these the only CVRs that will exist in Oracle EBS or will there be
more discussed in Sprint 2?

Can you please clarify what is mean by a "Null" segment value.

Is there an ACS hierarchy within BAS and if so what is it (e.g., bureau

code, fund code, program code etc. )?

How is work segregated across bureaus within the BAS Instance?

Is the expectation that the user should know the configuration

values (e.g., Fund Code etc.) for each transaction?

Can you please confirm the error message for Cross Validation Rules
will be changed from "null value" to "zero filled value".
Can you please confirm the CVRs will now include Bureau?
Will there be a way to track CWIP activity the similar way?

How was the NOAA Service Set determined? What is included in the
NOAA Service Set?

Is the NOAA Service Set just the 3 bureaus?

Will the bureaus be able to set the data access set rules for their
own Service Set?
Do the data access set rules have to be the same for all the bureaus
in the service set or can they be unique for each bureau?
Can you please provide Oracle EBS/BAS terminology documentation
(.e.g., NOAA Service Set)?
Because of the integration with PRISM and Sunflower - will we be
able to get the integrated data from who ever cross serviced a
contract? For e.g. if the NIST Acquisitions Office does an agreement
for NOAA, will NOAA be able to see the data if it is not in our NOAA
Service Set?
What does Chart of Accounts mean in EBS?
Is there a way to make sure that users can process valid compliant
USSGL transactions vs. line by line USSGL in EBS?

Is there an effective/expiration date that controls data segregation in

the event a bureau changes service providers?
If a bureau can only see their Operating Unit, how will cross servicing
work in EBS?
Does the Org code map to NFC Org codes in EBS? How do Org codes
map in the ACS and at what level of the Org code? How do GL05 and
GL06 map to the org in the ACS Structure? Is this a line office,
subdivision?
What are the portions of the Program Code; how is PPA identified in
EBS?
What is the process for a user to manually enter a transaction when
it is required now that a USSGL is part of the ACS?
Defined on GL062: Assigned on CM004 : Is this from the Project Code
setup for Goal?

Defined using Summary Level Transfer Transaction for one sided and
two sided - is this a conception in EBS?

Is the Activity Code the same as PPA?

If the new ACS structure has 5 segments for the org code and our
current CBS ACCS has 7 segments for the org code, should the Org
code have the same number of segments that NOAA currently has
administratively?
Is the new ACS org code going to start with bureau code or will the
org code start with the line office?

The current OC has an 8 digit object class and the new ACS structure
has a 6 digit object class. A NOAA program - OCIO Fee for Services is
tracked at the 6th digit so for this NOAA program we will be short. -
Different Contract vehicles calculate service fees - tracked by CBS
Object Class 3 and 4 which is the 5th - 8th digit of the Object Class.
How will these programs be tracked and how will surcharges get
picked up if we do not have the 4 extra OC digits?
Would you be able to provide a walkthrough of the ACS and its
components?

Is there a BAS Dictionary available?

Will Oracle EBS have Transaction Codes or a similar concept for

journal entries?

Since Project is not part of ACS. Please explain how Project and Task
codes will be used and how it relates to ACS and
transactions/charges. How does ACS work and impact General
Ledger Postings.

How will users understand all the GL hits. For GJ - the users have to
understand the posting logic. If they are not related to TC codes the
risk of incomplete entries is much higher. How has this been dealt
with at other agencies?
Since Project Code is not a part of the ACS, how does it relate back to
CBS?
What is the definition of Project Code? Will all Core Applications use
Project Code?

How does the Project Code in EBS map to the PPA?

Will there be a Direct Project Category? What about the other

projects that are not indirect or a reimbursable project? Can you
please provide an example of the other types of project templates?

Where are Capital Projects and Direct Projects covered?

Can you please provide additional information on Capital Projects as

NOAA will likely need to use this type (e.g., CWIP, IUSD)?
How will the conversion of existing projects in CBS occur? How will
the old CBS projects and the new EBS projects map/tie together?

For invoice processing, please clarify how and if the ACS is

independent from the Project and Task?

If the project derives the full ACS in EBS - is there only one Project for
one ACS string including the BFY?

In the EBS hierarchy does the Project come first and then the Task?

How do the existing Project Types in CBS crosswalk to the Project

Types in Oracle EBS (e.g., GEN, REIMB etc.)?
For reports, are there parameters that allow you to run by Project
range?

How is the Direct Project Type accommodated in the process flow?

How does the project get mapped to an ACS in the high-level

Projects process flow?

Where are Capital Projects and Direct Projects covered?

If you set a start or end date, can that be updated once it is entered?
Even after it has been used?

What is meant by Indirect Project?

How will project codes be traced back to a Program Code? Where
will the logic be captured outside of the project and task going
forward in BAS so that projects can be tracked appropriately?
For reimbursable agreements will cost be incurred against the task
or the project? How will Reimbursable agreements be used to
control the end dates?

If you set a start or end date for a Project or Task, can that be
updated once it is entered?
If the current plan is to have the auto numbered project number
include the FY will this be the FY the project is created? Do we have
to create a new project for each year (e.g., 30 month life of a
project)?

How will auto-numbering work in EBS as it relates to projects moving

forward year to year? Is it just the FY auto-numbered or are other
parts of the project code number also going to be auto numbered?

If possible could the Bureau Code be used as the first numbers in the
Project Code rather than FY?
Does Project autonumbering have to be used for all bureaus in EBS?
Is it possible to include "letters" similar to the way it is in CBS for
Project Numbers?
If project autonumbering must be enabled for all bureaus, is there a
field available in the Project where notes could be added to mimic
the Project Numbers in CBS?

Will every separate charging org have to have their own task value?

Can task be charged to different Funds within the same project

code?

Please clarify whether a 8 digit Project Code was decided on or was

that just for the walkthrough.

If you site different funds at the task code level can you explain how
Projects and task codes will work in EBS?

Will EBS have any system edits so that Project tasks cannot be
altered (e.g. so users cannot change anything in the Project
number)?

Who will decide and how will it be decided who gets what roles in
EBS?

Are the burden calculations controllable at the Org Code level within
NOAA?

Can you describe the single cost allocation method more

completely? Is it based on object class, object type, other?
Where do the calculation amounts come from and where are the
entered in the system?

Will the surcharge amounts be adjustable at the org code level

during the year?

What do you mean by source, targets, and conditions? Surcharges

are accumulated at a more detailed level in NOAA today, will there
be that flexibility in BAS as well?

What is the flexibility in reporting and how can we adjust (monthly,

quarterly, annually)?

NOAA assesses some specific overheads based on other object

classes, for example, acquisition fees based on a percentage of a
contract obligation. Will this type of capability exist in BAS?
How does the EBS know which burden cost to apply first? Is it by the
order listed on this screen?
Does the system allow you to define the order in which to apply the
multiplier?
Is there a limitation on number of multipliers?
If all multipliers have the same priority, how does EBS know what's
the base of the multiplier?
For NOAA Surcharge templates, each organization and FMC have
their own template with their surcharge rates. How would this be set
up/look in EBS?
Can we create new burdens anytime during the Fiscal year, or is it
locked in for the entire Fiscal Year?

Are versions the same as the current over/under concept? Is there

any accommodation for creating the over/under capability in BAS?

What is meant by the Type (Firm/Provisional) on the burden

schedules form?
Will invoices submitted electronically for awards be addressed in
Sprint 3 Vendor Portal?
Will data validation be handled electronically in Oracle EBS?

Is the invoice created and matched against the PO receipt the same
as the PM003 in CBS?

Who enters the invoice data into Oracle EBS? Will it be manual?

How will Oracle EBS check that the data is correct? Where are the
controls in the system?
What are the invoice types in Oracle EBS so we can identify which
document should be processed? Will there be a receiving ticket,
estimated accruals etc.?

Can you describe the process for No-Match invoices in Oracle EBS?

With larger payments will the obligating document be available for

review and certification? How will obligating documents be
accessed? Will permissions be granted to review the obligating
documents?

What does "Create Accounting" mean in the process flow?

Is there a way to update the invoice number to a parent account?

Can payments be handled line by line or this a way to handle
corrections at one time?

What does the correction button do?

How will the data be uploaded to the AP module for payment

processing or for gl posting only?
Upload of Data - into PM003 - this is not interfaced - how will this be
handled in Oracle EBS? (e.g., FedEx/UPS Payments)
How will Oracle EBS be configured to set up frequent payments that
do not have invoices (PM020) (e.g., Recur Payments - Leases,
Observers etc. - ?
What is the mechanism for recording IPAC invoices (generating for
income coming in and also for the accounts receivable expenses) in
Oracle EBS?

In reviewing the process flow, it appears it is high level and seems to

be missing some of the key decisions process flow elements
required. Would you be able to provide additional information about
this?
How will the system calculate discounts and interest penalties? Are
those customizable by document, invoice and item type? If so, how
and what would standard configuration be for DOC? Please provide
the specific configuration values that are established for Prompt Pay
and discounts, how they are controlled by document type, item type,
line type and what is the CM process for theses values by
bureau/department?

How is the payment determined to be 1099 reportable for tax

purposes?
Will EBS have a field to recognize 1099 filing status and how will this
process work in Oracle EBS?
How does the system identify if a transaction is subject to Prompt
Pay?

How will Oracle accommodate workflow in BAS?

How many levels of approval are available in workflow?

What is the review, receipt process and how it gets routed for more
than 1 level of approval?
Can workflow be different for each document type?

How will CD435 documents be handled in Oracle EBS (obligating

docs that do not get processed or managed through PRISM)?

Please explain the manual IPAC process in Oracle EBS (in CBS it is the
PM041 process).

The example in Oracle shows Qty x Price to give an amount view.

Will the solution be dollar based vs. quantity based? How will
rounding issues be addressed? How will Prompt Pay be calculated?

In CBS for every line of acctg. there is a description of how it is

calculated - is there a note or a description field in Oracle EBS to
explain how the fields are calculated?
If there is a matched invoice, can you have a combo of matched and
no matched line items?
How is tolerance calculated (e.g., travel) and how is it controlled at
an item or document level?

Who enters the receipt data for the 3-way match?

When tolerance is invoked can it be different based on line item
type?
How is interest handled in Oracle EBS?

How will the system determine the hierarchy of how the system is
configured to calculate dates? For example with interest penalties
(receiving ticket, receive invoice, process document etc.)? Which
date will be used for processing? Please clarify the date logic.

Travel CBA - matching payment to PO # = when PO is higher than

applied, the line is closed in CBS and NOAA has to create no match
lines. How will this work in Oracle EBS?
For all flows, can you please walk through in detail what each box
means?

How will adjustments be occur with invoices? (line of accounting vs.

DAR)

How will the system handle deobligations?

How will reporting for Accounts Payable be handled?

For invoice validation - how is this applicable to - 2 way, 3 way, 4 way

match?

Who is validating and who is approving invoices? Are they two

different people? If so, how are the various people notified?

Will the system email the next person for approval or processing of
payment? Or will there be a queue to identify what needs to occur
next in the process? How will notifications occur?

Which roles are currently responsible for validating and approving

doc invoices?

How will validating and approval of invoices occur today in Oracle

EBS? Will the responsibility of validating and approving invoices be
handled Acquisitions Office via PRISM or will the current process
continue where invoices are validated and approved in the Finance
Office?
What are seeded invoice holds?

Do invoice holds factor into Prompt Payments?

How do we put funding back into an Obligating document without

having to create a mod?

How will the user get a near real time view of the general ledger if
documents are batched from the subledger?

Can you change how frequently documents are pushed to the

General Ledger (especially around month end and year end)?

Can you please explain the disbursement process in Oracle EBS?

How long will attachments on invoices stay in the system? What are
the limitations that will be implemented so NOAA can obtain copies
of attachments and records? What is the file size limitation?

How can documents be flagged for "legislative holds" so that

attachments and documents be kept?

Will there be enough storage for record retention and legislative

holds?
Will there be a requirement to always attach an invoice in Oracle
EBS?

Is there a tolerance table in Oracle EBS?

Will partial payment occur if the individual line items for one invoice
are approved via the interface?

Will bureaus be limited to selecting only accounts within their

bureau?

Will BAS allow updates to the invoice number for interfaced invoices
at the end-user level?
If the supplier has multiple remittance for various contracts, Where
do you select the banking to use for that invoice? Or is it assumed
you would always have a 1-to-1 relationship between the contract
and remittance information?
Can multiple line items with different accounting be added?
Is there a way to reconcile the days payments at either the individual
level or at a group level?
How is timeliness determined in Oracle EBS - all we see is the invoice
date? How will timeliness be calculated? What are the precise
steps/calculations for determining when Prompt Pay starts in EBS?

Does an MDL Level exist in PRISM or EBS (if you have 4 or 5

accounts) - Will we need to rewrite contracts so that each MDL is a
separate line in the contract in order for the information to be set up
in EBS? Will each "MDL" be required to contain the appropriate
units and amounts for Matching purposes in EBS?
Is the Lines tab in EBS the same as CLIN in CBS?

How does project and task on the PO interface from PRISM to EBS?
Will this be done at the MDL level?

Is there a "invoice received date" in the Header portion of the

Workbench? "Acceptance Date?"

Is the invoice number unique? Is it unique within a vendor, within

the instance, or across all vendors?                   

What happens if a user doesn't select the funds checking on a

manual invoice? Will the system still stop and require it?
Is there a mechanism in EBS to prevent the invoice from being paid
before the acceptance date has passed?

Is the Matched Basis always quantity? Or can it be based on price?

Can insufficient funds be overridden?
How will vendors be handled in regards to the vendor file and
matching? How will foreign vendors, invitational travelers etc., be
handled?

For submitting reportable income for the vendor to the IRS we would
be prefer to have the IRS Consent tax payer information that is in
SAM to be used for the name and address on the 1099 forms and
not the remittance address (currently used). Is this possible?

How will Sub Invoice Numbering concept be handled in EBS? NOAA

uses sub invoice numbering for CBA Invoice, Motorpool, Recur
Payments and Telcom. Sub invoicing is not just for Bank Card.

Who can see the commitment that is coming from PRISM in EBS ?

How is the CAGE code from SAM.gov interfaced with EBS? Does
each vendor DUNS can have multiple CAGE codes?
Will the step by step process for calculating each field be discussed
in a future Sprint?

Is the workflow based on the NIST model?

Is anyone at the Line Office providing input on how invoices will be
submitted for payment?

How will EBS determine which invoice is subject to Prompt Pay and
how interest is calculated?

Can you describe the steps for the recommended invoice workflow
from the invoice receipt (how and by whom) through the
disbursement of the payment?
What happens to the invoice after the COR approves/certifies the
invoice?
Is it possible for invoice processing to start in PRISM (just the ones
that are matched through PRISM)? Will the invoice in PRISM get
approved?
Will PRISM ever get updates from Oracle EBS? If so, what
information is shared?

Who will define the roles for AP Invoice process? Will we have input
before the recommendation is provided to us in the next Sprint?

Whose role is it to complete each process in the VISIOS? What is the

definition of AP Technician (are we assuming it's the Finance Office)?

Is "Payment Processed" the disbursement process?

At the invoice creating and matching against PO box, it then goes to

validation and then approved, the approval is the COR - is that a
definite role or can suggestions be made that are interchangeable?

Could you please provide more details around the Manual Invoice
process? Where is the accounting information obtained for this
type?

Where in the PO is the tolerance defined?

Can you provide greater context on how Finance enters the data at
the first step in the invoice processing workflow when Finance does
not have the invoice or accounting information?

How do you select the correct remittance information (aka banking)

for a Supplier with multiple DUNS and banking information?

How are invoices batched and routed? How do you perceive the
batch process screens to be used?

What is the receipt date? Is this acceptance date or invoice received

date or goods/service received date?
Is that a pop up message or do you have to run a report?
When would you use Draft/Final or Final Post? Who changes those
status?
What doesIs it "EBS
system
willgenerated
not act asor manual?
a file repository" mean? Does this
mean EBS will not be the system of record keeping for invoices? Do
we need to keep a duplicate file outside of EBS? What is the file size
limitation of each file uploaded and how many files are allowed?
What is the difference between required (validation vs accounting)
before approval?

At what level is the tolerance determined? Is it invoice type, cost

type, etc.?

Whose role is it to complete each process in the VISIOS slide 10? 

What is the definition of AP Technician (are we assuming it's the
Finance Office)?  What happens to the invoice once it is submitted
for payment?

Where is the accounting information obtained for this type?

Can we get a listing or ask about the AP Module attributes/data

fields?

What does "CVS” stands for?

How is the system configured? All payments subject to Prompt Pay?

Or is it only for match documents?
Does an invoice have to be batched or can it be processed manually
one at a time?
Is 1099 reportable determined by Supplier and object class?
Are the project and task are required fields? Are these used to
generate the ACS? How does this affect No Match documents?

Will PRISM be the c-suite replacement?

For Receipt Location, are the locations restricted to each Finance

Office or will it be the actual location where the goods were
received?

Can you explain the purpose of using the "validated related invoice"
button?
How does the AP Technician know whether the invoice is 2-Way or
3-Way?

Can a PO have more than one type?

Sometimes vendors offer discount term, will EBS have the place to
record this? Will we see an example today or in the future?

Where will the project and task be created?

Where would the multiple accounting lines in each CLIN be reflected

in the workbench?

Will we begin to see examples of scenarios during the demo from

a Census and NOAA perspective?

Will there be responsibility levels for all smaller levels?

For 2 way or 3 way match fund checks, if one of the lines has
insufficient amount but the total UDO has enough funds, will the
system give a warning?

When the ACS information was put in, there was only one account
identified. How are the additional accounts derived?

Does Oracle check for special character (hard return) in text boxes?

Can you change the quantity invoiced to get the error?

When looking at the workbench how would you know that a file is
attached?
Do we need to redact any PII and/or BII on any attached document
before routing for approving?

Will we be able to do a short pay for the available remaining fund?

Is it possible to lock down an attachment once it has been applied to

a record?

When a user mistakenly chooses the wrong line of accounting and

deletes that entry, does EBS post the mistake on the GL?

Will the payment information be interfaced back to PRISM?

Do we need to have every invoice in the batch approved before
allowing to submit for payment? Will there be any change for
payment submission to the Treasury in EBS?

How will the approval process work in EBS for routing of documents?

My understanding from the meeting is the BAS team is analyzing the

differing bureau invoice processing workflows looking for
commonalities and pain points. Is it possible for us to be part of that
discussion? Will a specific meeting for this topic be set to discuss
what was determined?

We are unclear what the workflow will be for non-interfaced

obligations and we don’t see it listed as part of a future Sprint. Will
this be included in a future Sprint? Will the workflow of a non-
interfaced obligation be addressed (e.g. training documents)?

Could you explain how the BAS PMO effort will be different from
what we will need to provide as part of the EDW Financial
Community? How can duplicate effort be avoided?

For all the reports listed, will Project, Task and Subtask be included
on each of the reports? NOAA would like to have Project, Task and
Subtask included on each of these AR reports. The Project, Task and
Subtask should post to the GL.
For reports not available in CSV or excel format, will those reports be
made available in the EDW for download into excel?
Will the transaction tables in EBS be replicated in the EDW for
custom reports in the EDW?

For every report that is in EBS, will those data elements be available
in the EDW?

Will reconciliation reports that compare year over year be available

in EBS since the ACS is changing? How will year over year reports be
tracked in EBS? (e.g., For the agreements that last 5 years and are
still active when we transition into EBS - how can those agreements
be reconciled from year to year?) Specifically what is the BAS open
document conversion plan?

Can you please share the names, purpose, data elements and sample
of the 160 AR reports?

Can the times for running the AR reports be bureau specific?

Is the intent of the provided AR playbook for reports a conceptual

process flow for year end?

Are you expecting feedback for the bureaus to elaborate on their

Month End Close and Year End Close?

Can you run reports for each class separately?

Will there be a user manual on these reports? What does the help
section offer on this screen?

Is it possible to run AR reports specifically for federal and non-

federal customers (e.g., use a customer type)? If so, for federal
customers we would need Trading Partner (TP) main information.

What is the bills receivable category on the AR reports?

Currently in the ARSI we get a number from the Seafood Inspection

program (SISP) system. Will this number show up on an AR report?
What is a wash account and how is it used in EBS?

Is a wash account the same as a clearing account?

Our standard remittance process differs from what is depicted. We

deposit paper checks via Over The Counter Channel (OTC net), once
the deposit is verified NOAA enters information into AR006 and
AR007. Since we don't get verification (a receipt) from OTC Net, how
will we be able to enter a receipt without the verified deposit
information?

How will separation of duties (SOD) work within EBS? Where are the
breaks to ensure SOD is adhered to?

How will the deposit ticket be implemented in EBS? Deposit and

voucher number do not appear to be addressed in these slides.

Is there a batch or bulk option where you can receive bulk receivable
checks?

Specifically, is there an ODI capability for processing checks that

have been loaded to a file into the receivables module?

Will there be a standard automated AR interface for seafood

inspection?

If we have a receivable from seafood inspection and then get the

associated remittance through CIR, can we use the "Bills Receivable
Remittance" method to join the receivable with the remittance?

The deposit ticket # is shown as part of the standard remittance

method. How about in the no-remittance method? Will this field be
a part of this process?

What is the difference between standard remittance and no-

remittance methods?

Do the AR and AP screens talk to each other?

How does this relate to AP/AR Netting from slide 5 of the

presentation?

Using the DEFC Code as the attribute for Fund Value code position
12, represents the most straight forward tracking of funding. Please
provide NOAA with the most recent version of the crosswalk
between CBS codes and EBS codes.

Please provide an explanation on how EBS will accommodate TAS

Parent/Child relationships within the proposed fund value?
Can we have a higher parent to all the children for apportionment?

With the current recommended approach, NOAA anticipates a

quadrupling of effort from what we currently do today. Can we allot
at the EBS 2/3 level (which is equivalent to CBS Program level 1)
instead of going to the EBS 7/8 level? Can each bureau enter
apportionments at the level that works best for them?

Will any of the override tolerances controls allow for no match

transactions to post? Are these tolerances mandatory to be
established? Can each bureau set tolerances or is it standard across
the bureaus?

Is the reprogramming screen the equivalent to the CBS BOP transfer

process? If so does it automatically adjust the allotment?

Can you provide additional information on the CR process? What is

the implication for budget year and CR?

Since reimbursable are allotted at the CBS project level and currently
project/task is not part of the ACS, how will we be able to see the
entire accounting string for reimbursable?

How will bulk files that contain IPACs be handled in EBS?

How will the variation we have for IPACs be handled (e.g. no match
transactions, IPACs without a purchase order, IPACs for rent,
Motorpool, IPACs with no terms and conditions set up, bulk files,
IPACS were 7600s are not established etc.)?

GSA Rent is handled via SLT. How will GSA Rent be handled in EBS to
allocate the costs across multiple ACS strings (i.e. IPACs for Rent are
distributed through SLTs to many FMCs (orgs) within a bureau)?
1)Will G-invoicing for IPACS accommodate bulk files and also
accommodate IPACs that are not bulk but are just one record (e.g.,
IPACs for USDA for Seafood Inspection program (NOAA's inspections
on behalf of USDA customers))?

2)Will G-invoicing for IPACS accommodate a group of files such as

IPACs from Treasury (i.e., cases referred to Treasury for collection)?

3)Which documents and transactions will be part of the G-Invoicing

solution?

If IGT IPACs will no longer be entered or interfaced in IPAC, how will

this work in EBS?

Will there be an equivalent APSI and ARSI capability to upload

transactions that are Receivable or AP related for IPACs into EBS?

On the requesting side, how will we receive the invoice? Will the
invoice come through G-invoicing?

How do G-Invoice transactions tie out to Reimbursable Agreements

and tracked within EBS? How do you identify if a receipt is a
Reimbursable or an Accounts Receivable? Without an agreement
number or something equivalent how can this be tracked? How will
the bureaus know which transaction is a reimbursable vs. receivable
such as an inspection certificate?

What is meant by "Initiate Payment" on the Disbursing agency side?

For example, for BIS there is a program VSSTF, where some of the
cases fall under this program. We have to send a percentage of the
collection (e.g., 75% of collection) and then we have to request those
funds to be transferred via IPAC to DOJ. So in this case we initiate
payment to DOJ for this program. How would this work?

Today we have situations where we have a refund for a Federal

Agency (i.e. there is a credit amount on the Reimbursable project
code and tied to a Reimbursable agreement) but because it is a
Federal Agency it is handled via an IPAC. Would this go through G-
invoicing? How would this scenario work?

How will court settlement payments be processed in EBS?

How will DOD investigation fees and transportation subsidies be

handled in EBS?
Other Non-Buy/Sell transactions do DOC Bureaus perform in IPAC?
- PCS (federal tax withholdings - and IPAC), adjudication fees

Recorded through APSI, ARSI or CBS AP or CBS AR Screens.

Which documents and transactions will be part of the G-Invoicing

solution?

It seems the focus has been on the OTC IPACs and not the PTP IPACs.
When will the PTP requestor side be discussed for IPACs?

For Non-Buy/Sell transactions, will these hit the GL? How will these
transactions be posted (GL, SL or Projects Module) in EBS?

Will the Non-Buy/Sell transactions be processed through the Project

module?

Is this example of refunds for the AR side or reimbursable side?

For the reimbursable side, NOAA needs an agreement number to

process these transactions.

Can a user enter a different ACS for the $9,000 and $1,000?

For example, for Seafood Inspection. We received, $10,000 and

$9000 was applied to the project and task 2KLxxxx. a $1000 amount
is being refunded which comes from the NOAA suspense account,
which is a different project and task NDO03880-P00.

How is the AR screen going to link and create an AP screen for a

refund?

Is there a control that checks to see if there is a supplier set up for

the customer before a disbursement is created?

Will we have to select a vendor number from the screen?

Is this related to the supplier and customer relationship type of

refund?

Where is a reimbursable agreement identified? One customer may

have several agreements over multiple years for different projects
How does the AR module differentiate between a Reimbursable
receipt vs an AR receipt? How does that relate to the management
of Reimbursables in the Project Module?

Does this process apply to agreements (reimbursables) as well as

AR?

Will bureaus be able to see just their own refunds or will they see all
refunds that are available?

For reimbursable transactions we currently set up an allotment for a

refund, will we need to do that in BAS as well?

We do not see a field for reimbursable agreement number. NOAA

would need to add that as an attribute to process refunds.

For AR, if we apply a refund, can we change the accounting? Can we

do partial refunds?

If I understood correctly, are we saying that Supplier Maintenance

will be handled centrally by DOC? If so, that is not the conversations
the bureaus have had with BAS PMO where the operational
components like Customer and Supplier Maintenance would remain
at the Bureaus.

Please explain in more detail what is meant by pre-deployment

process?
For reimbursables, will the refund process be the same for an
expired agreement?

In CBS, the PM402 vendor payments screen shows all the vendor
information. How will we be able to verify the banking information in
EBS? We need to make sure the supplier and customer are the same.

At a specific detailed level, how does the credit/debit memo affect

the UDOs in terms of obligations balance?
Can you clarify what the postings are for credit and debit memos?

Can you provide an example of when we would use Credit/Debit

memos?

Are there any checks in place to verify the debit/credit entries made
are correct?

If we pay the final invoice, can a credit/debit memo be applied?

Does EBS track the status of a PO? Once a PO is closed can any
adjustments be made?
Will EBS notify vendors about offsets and credit memos? (RTM item
PM217)
If the final invoice flag is selected, what happens to the funds
remaining on the PO? (RTM item PM105)
If a credit memo is received, is it paid on a future invoice to the
vendor?
I'm looking for additional information performing specific actions in
SAMS RP. Where can I find this information?

I have heard about the BAS Real Property Change and Control Board
(BRPCCB), but I want more information. Where can I learn more
about what the BRPCCB is and how it relates to BAS Real Property
Production Support?

I want to submit a request for an enhancement. Will that result in

changes to the system?

When will testing occur for the GSA Federal Real Property Profile
(FRPP), as related to DOC's Sunflower Real Property module?

As configuration changes occur after Go-Live, will I be updated on

how to use the system with the new enhancements?

The accounting system needs the actual receipt date to properly

process - it cannot be a "YES" or "NO" as depicted in the process
flow. Could you clarify?

PO is interfaced to EBS requiring a receipt and invoice match. Is

there an expectation that this part of the process occurs before we
receive an invoice?

What does the PO Rev field refer to? Is that similar to a task order or
a change order in CBS?
Are we using the Treasury's IPP system? If yes, will all of this data be
interfaced from IPP to EBS and populate these screens? Or does EBS
have a document management function to route receipts for review
and approval?
If it is a 2-way invoice, will operations be able to override the invoice
received date in EBS?
For the receipt date on the Receipt Header Form, how does this
correlate for the invoice receipt date for paying the invoice and
where do the calculations (e.g., for Prompt Pay) occur?

For receipt remittance what is meant by "accounts"?

During the meeting "accounts" referred to both the "complete ACS

string" and the "USSGL". Could you please clarify which is correct?

What are the following "items" categorized as: Cash, Receipt

Confirmation, Remittance?
- What is Cash?
- What is Receipt Confirmation?
- What is Remittance?
Are we limited to only these 3 "items"?
What is a remittance batch? For remittance batches are CIR and
Pay.gov included in those batches?

How does a receipt get applied to a Reimbursable Agreement? (need

customer number/name and an agreement identifier)

When will there be a session on the no-remittance receipt types and transactions (e.g., pay.gov, fedwire, credit card, ACH) tha

As mentioned in the Receipts Common Solution session in January,

NOAA's current process is to clear the checks before the receipts are
entered into the system. In March, the DOC BAS Team responded to
a NOAA question stating "Entering a receipt first without the verified
deposit information is an optional process. NOAA can always first
send the checks for clearance and then create the receipts".

NOAA would like to confirm we can still follow our current process of
having the checks clear before creating receipts in the EBS system?

What's the difference in the process where it is not a check and we

go to OTC Net and have this other cash (FedWire, ACH) coming in?

Everything today is handled manually except for Seafood Inspection

which is handled via an interface.

What happens in the receipt process if the bureau does not have a
bill?
Will we have to set up an ACS for anything that is unidentified?

To confirm, NOAA would provide a default account (e.g., 3880) if we

are unsure where the cash should be applied.

Please confirm that receipt method is nothing more than a label

specific to Creation Method, Remittance Method, Clearance method
etc.

So one receipt method for a "Manual" creation method could be

Fedwire, another one could be ACH, one could be Pay.gov, correct?

If we have one voucher number with 5 payments which could have 5

different ACSs, how will this be accommodated in EBS?
This applies to the Account Receivable, Reimbursable and Funds
Management teams where we currently have separation of
duties/roles for Receipt Remittance. Separation of duties and roles
are audited.

Currently, our Financial Reporting Division - Funds Management

Branch (FMB) sets up receipts and deposits, and posts collections in
the CBS Unbilled collections screen. It's not separation of duties now
(unless it is because FMB does not collect in the CBS Billed
collections screen), so why is it changing for BAS?

When setting up the deposit ticket, will the Accounts Receivable

Branch or the Reimbursables Branch pull in the customer
information?

Can we update the receipt number field?

How can the unapplied amount be tracked for the deposit ticket
number?

What edits can be applied to the fields proposed for Deposit Ticket
to ensure consistency? Deposit Ticket is used for CARS reconciliation
and will be important to ensure ability to match.

Receipts for Reimbursables are applied by Project Code if unbilled.

Receipts for Reimbursables are applied by AR number if billed. How
will this be accommodated for the reimbursable side in EBS?

For deposit ticket batches, is it possible to reopen a "closed batch"

and make the necessary correction? If so, how can you make the
correction?

Sometimes if a receipt is applied to the wrong project code or

deposit ticket, we have to reopen the batch, fix the issue, repost the
collection and manually close the batch.
How will dummy tickets ($0 ticket that has a negative for a specific
amount and positive for a specific amount) be accommodated in
EBS? This is used often for loan refinance and buy back adjustments
(e.g., CBS and APEX do not match).

For cash receipts for Reimbursables (e.g., NESDIS - 56N3ANE), when

we transfer the total amount collected from the project and
reallocate to smaller projects a dummy ticket has to be created
(from 1 ACS project/task code to many ACS). How would this be
accommodated in EBS?

Dummy tickets are also used to move funds from one FY to another
FY for Reimbursable Agreements.

When we receive receipts, can we create batches of 1? Do you

always have to create a batch for processing? If you get just 1 receipt
can that just be entered on its own?

What if there are for example 5 separate batches from CIR, are those
5 batches processed as 1 big batch or are they processed
individually?

Can a batch be a deposit ticket that has all the related receipts for
that deposit ticket?

When creating a batch, the slide mentions that multiple people can
enter receipts at the same time. Can you explain how exactly that
will work in EBS? Are we having multiple people work on one deposit
ticket?

Is the requirement that multiple people have to work on one

batch/deposit ticket or can just 1 person work on the batch/deposit
ticket? NOTE: This is a different process than is currently followed by
NOAA today - we have 1 person working on a deposit ticket.

1) Will there be an interface for the Lockbox?

2)Will there be an interface for any other payment methods such

Pay.gov, Fedwire, credit card, ACH etc.? Will there be an interface
for Seafood Inspection? We understand this could be a future
integration discussion, but it would be helpful to understand how
this will work during functional sessions like these.

We understand the Lockbox field cannot be modified. However, how

and where can we enter the Deposit Ticket #? On the Receipt
Batches screen, is the Lockbox field auto populated or can we
manually enter the Deposit Ticket #? NOAA will need a way to
identify the Deposit Ticket number.

Could the Reference Number field be used for the Deposit Ticket #?
Will the batch number equate to the OTCnet?

Can you please explain how the summary data entry process will be
easier and less time consuming?

For the Pay.gov Common Solution Session on 5/4, could you please
also cover CIR as well? It would be helpful for the BAS Team to cover
CIR in the discussion to fully understand the full picture of this
process.

How will the information from Pay.gov and CIR be included in EBS?
Can we please discuss and also see the detailed specifications?

We have to pass the information to internal NOAA development

teams like SISP so they know what changes they need to make to
their own interfaces and give them adequate time to plan, build,
test, deploy etc.. We cannot wait until the NOAA implementation
year to provide this information to our internal NOAA teams.

When costs are accumulated for Reimbursables in the Projects

Module is there a process that assigns them to an agreement?

Currently we have the WIP that pulls costs out of trials for
Reimbursable Project Code and assigns cost to unfilled customer
order that is part of Reimbursable Agreement and billed to the
customer. We understand when the bill is generated it will be part of
GINV, but what generates the bill?

The slide says "Orders approved by Requesting Agency will be

interfaced into BAS" does this mean GINV is creating the obligation
and automatically obligate the funds in EBS?

Will the 7600A and 7600B forms be stored in EBS as a PDF

attachment?

Our understanding is that GINV allows a user to attach as many

documents as needed for the agreement. Will those attachments
flow over into EBS?

Will the unfilled customer order be created in EBS via GINV interface
or will the unfilled customer order have to be manually entered into
EBS?
We understand that performance will be discussed at a later session,
however we would still like to understand how does EBS pull the
transactions/costs to create the bills. Is there a process that the user
needs to kick off? How does that work?

Will there be document chaining within EBS (e.g., Agreements,

Purchase Order, Invoice etc.)? Will there also be document chaining
between GINV and EBS?

With GINV, will the 7600A and 7600B create an agreement (in CBS
RADG002), unfilled customer order (in CBS RADG003) and an
allotment (in CBS FM063) on the Reimbursable side within EBS?

Will a Reimbursable Agreement be associated with a Project in EBS?

Will GINV through the interface create a new EBS Project for the
agreement?

What is meant by "Customer Agreement" in the statement "Create

Customer Agreement from order, Approve or Reject Agreement"?

Does the Customer Agreement have to do with an allotment?

Does Customer Agreement mean IAA?

Is the agreement creation automatic or does it need to be created or

approved manually in BAS?

Will AP Bills be interfaced or manually entered into EBS for the

Requesting Agency?

NOAA as Requesting Agency - does the process start in EBS or does it

start in GINV?

During the meeting, it was mentioned that the BAS Team would
follow up on the following question:
Will Receipt Method or Type be used to identify an advance
collection?

Please let us know what you find out.

Will EBS kick off the billing process automatically according to the
selection in the billing frequency (e.g., weekly) or will the user have
to manually kick off the billing process? Is this a required field?

After the TAS, BETC - there is a field called schedule status. What is
that related to? Please let us know what you find out in the
documentation regarding performance obligation.

Cost allocation control -

Allocating cost to the order and the agreement. Order of cost

allocation in CAMS where the procurement cost went against the
order - refunds would be negative cost - negative bills for WIP

How will costs be accumulated? What order will costs be assigned

against the unfilled orders and if they hit the max amount of order
before credits come through will processing continue?

Refunds should be applied first so orders are not closed too early
(would apply money to the obligation). Will there be controls applied
so there is no cost overruns?

Please note: Currently when running the WIP process (e.g. in CBS)
users cannot be in the AR module entering transactions - otherwise
tables lock and processing will stop. Will there be a similar process in
EBS?

How often will GINV be interfacing with EBS? Will interfaced GINV
transactions affect the WIP process (or the equivalent in EBS)?

Future Meeting Request: It would be very helpful to have part of a

meeting be designated to a walkthrough from beginning to end (e.g.,
looking at the 7600Z and B and comparing it to the entry in the
systems.) NOAA would be happy to provide a real life example with
documentation for use in a walkthrough of GINV and EBS.

What is meant by External Costs (e.g., interfaced data) and can you
please provide examples?

Beyond using the Project Module for Reimbursables, can you give
other examples and the reason for using the Project Module from
the perspective of Budget Execution?
The Visio does not appear to show the Accounts Receivable part of
the process. Can you please provide the AR portion for the Visio?
Slide 5 mentions AR but it is not shown on the Visio on slide 4.

Can you please provide examples of the Capitalized Project

Category? Is the Capitalized Project Category used for WIP Projects?
Is this where CWIP projects would be included?

What are the other Project/Task attributes that can be used to

describe Projects and help differentiate various Project Types (e.g.,
Direct, Reimbursable, Construction, etc.)? Where are attributes
established in the Projects Module? Project Type is heavily used in
Reporting and in CBS we have 50+ Project Types. Please provide a
direct mapping of the CBS Project Types to the EBS equivalent of the
EBS Project/Task Type.

Please provide a list of all EBS Project/Task attributes (i.e. NSF, R&D,
etc.) and any currently planned flex fields that will be used to
document these attributes to ensure proper tracking and reporting.

If the EBS Project Code is limited to only one owning organization

code, does this mean that the EBS Task Codes must have the same
owning organization code?

Please ensure that whenever organization code is mentioned within

the context of a Project or Task we clearly differentiate between
owning organization and expenditure organization.

On slide 6, it states the EBS Project and Task Code are equivalent to
CBS Project and Task Code. Could you please update the slide
presentation to show that EBS Project and Task are equal to CBS
Project and that EBS Sub Task equals CBS Task Code and redistribute
the presentation to the attendees?

Does the Task Code have to only represent 1 BFY meaning if it is X

Year money, do you need to create a new task code each BFY? If it is
required to create a new BFY, how are prior year upward and
downward adjustments prevented from improper GL hits?

If a new task code is required each BFY and the associated Sub Tasks
have to be recreated the operational overhead to NOAA LO and SO is
significant. What automated mechanisms are available to support
copy/replicate at the Task, Subtask Code level?

CBS Project and Task post to the GL which enables GJs /JVs to be
posted at that level of detail. Since Project and Task are not part of
the EBS ACS how will JVs be processed that were not generated
through the Project Module?
For some of our adjustments (i.e. SLT, DLA, DLCA), if posting a JV to
fix a transaction does it need to flow up via the Projects Module to
fix the transaction?

Across NOAA we use the same Task Code for reporting purposes
(e.g., TBM, IT charges, etc.). How will EBS Subtask enable this
capability?

Do the Project Code and Task Code have to be unique across DOC or
is it by Bureau?
What will be the standard for the Project length and Task length?
How do we ensure standardization and common business rules
within the framework of bureaus managing their Project and Task
values?

Can a 0 be used in the Task Code? There are some values in CBS
where we could not use "I" or "O". NOAA would suggest that
business rules be established so that I's and 1's and 0 and Os are not
used so we follow the same business rules across all of DOC for
Project code creation.

Will there be a differentiator in the Project Number for Org or Line

Office?
Today we have hundreds of project codes that relate to 1 capital
asset (e.g., construction of a satellite has multiple project codes
across multiple years). If Capital Project will equate to 1 capital asset,
what is the EBS mechanism to support this capability?

Will the combination of Fund Value, BFY and Program code need a
unique task code within the context of the Project Code?

Do we need to set up the same task for each unique project code or
can you pull in the task code for other project codes subsequent to
its creation?
What is the difference between the Account Generator and PA
AutoAccounting since they are both covered direct entry?

In NMFS, we have multiple PPAs used across FMCs that would have
the same project code but charged to their org.

How will this be handled in POET?

The project that AutoAccounting goes through goes directly into GL,
correct?

The diagram states that PA posts directly to GL not the sub ledger.
Please clarify.

Describe the way to roll over tasks and subtasks? Is there a way to
do a bulk upload?

If we needed to do a GJ, will it have the project and task? If project

and task will not be part of the ACS then how are project budgetary
control/funds tracking properly adjusted when there is a JV?

The way this bullet is worded - "The Account Generator concept or

feature in EBS derives the full ACS. You do not need to know the full
ACS string when submitting expenditure transactions in EBS." This
statement makes it seem that all transactions will be interfaced into
EBS. Not every transaction is interfaced in.

If Fund and Program are at the task level yet some of the attributes
such as Field of Science and NSF codes are at the project level how
does EBS reconcile attributes that are more specific to Funds and
Programs since they are not at the Project level? Does this imply
limitations on what tasks can be created (fund, program) based on
the attributes selected for the Project? (Today in CBS when setting
up, project maps to the Funds and Programs being charged. In EBS
setting up attributes at the Project but Fund and program are part of
the task level. Tasks can have multiple funds and programs. Does this
mean that we are limited on the tasks associated with a particular
project?)

Does Project Classification equate to Project Type in CBS?

What other attributes are available for the Project? There appears to
be a scroll bar on the screen shot but they are not presented on the
slide.
At NOAA we currently use Fund Code and Project Type. Can those
fields be added?

This is how we understand the project task: for instance, a loan

project code 2ELAQ21-P00 2ELAQ22-P00 could possibly change to:
2ELAQ-P0021 2ELAQ-P0022. Is this correct? If EBS project and task
combined equals CBS project, then the BFY concept at the EBS task
level would increase the postings across multiple FYs. Is this
understanding correct?
What is the entire list of Classifications? Please provide the entire list
of classifications available.

Is there a capability to add additional classifications in the out years?

Can these Attributes be standardized and added to over time?

What does Workflow in Process represent? Please provide a more in

depth explanation as to what Workflow in Process means.
Is "Organization" the same as CBS org codes? Can you have more
than one organization setup on the project template?

We are asking about expenditure org as part of POET. It appears

that the expenditure org is the same as the CBS org code, please
confirm.
Can you give us more information on the field in the Project header
form that is above the Change Status Button in brackets?
Regarding workflow in process check box on the Project Header
form, Does it correlate to the Project Category and is it a required
field if a Reimbursable is selected as the Project Category?
If EBS project and task equal CBS project, and EBS subtask equals
CBS task does POET become POETS meaning project, org,
expenditure (Obj Class), task, subtask?

Would NOAA still be able to have that project task, subtask level of
granularity for things that are not PO’s or AP’s? Please expand on
your current conversation you mentioned was occurring and what
you believe the impact is currently for this.

Do receivables go through the project module? Please provide a

timeframe as to when the patches will be applied and we can get an
answer to this question?

Could you please provide screenshots for all fields and values for the
Project and Task (there appears to be scroll bars with additional
attributes which are not shown in the screen shot)?
CBS does not require 000 for a task code. The requirement is a
project must have at least 1 task code.
Task code does not derive any portion of the ACCS in CBS. Task code
is just a required component of the CBS ACCS. 2nd bullet is incorrect.
Please update the slide presentation based on the discussion

This is incorrect - "EBS is similar, only that Task is driving more values
(i.e., BFY, Fund, and Program)." The CBS Project code contains all the
components for Fund and Program. Org codes are not posted to the
GL because you know a project and task. They are separately
entered in CBS. Please update the slide presentation based on the
discussion.

Can you turn on budgetary control for only certain project

categories? What are the various project types supported in EBS?

If using Burden Schedules for M&A, how does this map to the rest of
cost allocation in EBS? What is the primary difference for burden
schedules vs. cost allocation? Can you exclude individual projects
and task categories and what is the mechanism for that?
How many key members can be added to a Project? Is there a limit
to the number of people who can be added over time?

For the Cost Budget, do the Task, OC, Timeframe - do all of those
components need to be entered or can it just be done by certain
components like OC or Timeframe (as it is done today)? What is the
frequency of when this can be entered? Are there capabilities to
make adjustments over the FY?

Administrative costs for spend plans - with current process we use

the Internal Fund and also put in OC 77 on appropriated side. Need
better understanding of how administrative costs, burden schedules
will be handled. Need to be able to identify Admin costs by OC -
cannot all be under one OC.

Differentiate sources of Purchase, Payables and ext. source - we

interface the majority of data in the system (PRISM, Labor, Travel,
Telecom, Rent etc.). If they do hard stops (e.g., for the different
budget controls) what does that mean for interface integration?

Why would we use the Project Cost module for Funds Control? How
many places do we really need funds control? If Funds control is set
up at the Budget level why would we need the funds control at the
Project Code level as well? Please provide the diagram showing
where funds set up, funds control vs. project budgetary control are
used and enforced?

When can we see the status on cost allocation? During the

discussion it was mentioned that there were ongoing conversations.
When will you need the list of NOAA participants from NOAA budget,
finance, and Line Offices?

How will things like Admin costs be managed - will the burdens be
handled via the Funds/ACS Budget Control area or via the Project
Module?
EBS has cost allocation that helps with overhead - this should be
covered in next discussion as it impacts many budget areas.

Can BAS include quality assurance and quality control functions,

either at the onset or with the capability to create system checks in
the future? For example, there are many areas where staff can enter
inconsistent data. Currently Research and Development (R&D) funds
are tracked at the CBS project level and in BAS might be via task
code. So a logical system check would ensure that a task that is NOT
R&D is also not able to use OC 41-11 Research Grants. In addition, if
a rent related task code is used a rent related OC should be used.

Will there be an interface from WebTA into EBS or EDW that joins to
the NFC data feeds?
Can reports be run at the fund level? Can reports be run without the
additional attributes (summary level)?
Is there a trial balance report that can be run with selected
attributes, such as just by Fed/NonFed (and applicable TP AID and
Main)? This would aid in Intra-Commerce and Intragovernmental
reporting

Will the Unknown trading partner (999 9999) be included as a valid

TP value? There is limited activity with agencies (such as CIA) which
are reported under this value, along with some JV adjustments which
are truly unknown

For USSGL which allow a combination of NonFederal (N), NonFederal

Exception (E), and/or Non Reciprocating (Z), how will the system
know which value to assign on the GTAS bulk file since none of these
domain values use a trading partner? Example: USSGL 640000 has
balances with N and Z values

For quarterly departmental reporting in Hyperion (HFM) certain

attributes and domain values are required on the ETB which are
outside the USSGL TFM. How will BAS handle these scenarios?
Example: USSGL 480200 does not have a Fed/NonFed value in the
USSGL TFM, but is a required attribute for reporting to the
Department

Certain footnotes require USSGL to be split out by attribute domain

value which are not required by the USSGL TFM. How will this
information be captured? Example: reporting UDO balances by
Fed/NonFed (48xx00 balances)

For budgetary transactions attributes - Public Law, reduction type

and authority type, will these be part of Fed admin module or will
the values be derived from the attributes from the manual GJs for
GTAS reporting?
Will the user need to enter the attributes for the GJs for all Journal
lines or for specific journal lines. For GTAS reporting - How are these
attributes data pulled for subledger transactions?

Can GTAS process run for each bureaus separately? If not, how will
the GTAS exception be handled?

Data act attributes for Purchase orders - Will these attribute be

entered by the user in PRISM if the PO is created in PRISM and
interfaced to BAS EBS system. Or will the user have to enter this in
BAS EBS?

Data act attributes at GJ level - Will the Data Act attributes be

created as additional descriptive flexfields along with the other
attributes on Slide 13?

Cohort appears to be an attribute of the Fund Value in EBS. It

appears there is no requirement to make it a separate segment using
one of the reserved fields. Please confirm.

Can you please provide a screenshot of the Cohort Attribute in EBS

when available?

NOAA will have to override some of the GTAS Attributes even though
there are standard default attributes.

Will bureaus have the capability to override GTAS attributes in EBS?

To elaborate, 99% of the time, the PYA attribute should be 'X' for the
relevant USSGLs and this can probably be set as a default. Although
it has occurred where some transactions must either use a 'B' or 'P'
attribute for PYA based of certain scenarios. How can this be
accommodated?

Do bureaus have to wait for Oracle to provide GTAS updates in EBS?

How responsive will Oracle be in getting updates in the EBS system?

Will bureaus be able to make the updates when needed if Oracle

updates are delayed?

For example, NOAA has received requests to change the DEFC in CBS
prior to getting releases from the CSC in order to meet end of month
reporting. Bureaus will need the ability to make updates and
maintain the attributes when a new spending bill is passed - and to
add, spending bills (to include supplemental appropriation bills) can
occur anytime throughout the fiscal year.
We are still waiting to see the latest crosswalk of the CBS Fund Code
to EBS Fund Value. Second, the presenter during the Common
Solution meeting stated that characters currently extend past the
viewing field length on this screen can be adjusted. We will need a
way to see the full Fund Value on this screen.

How are cohort transactions accommodated in the GTAS Transaction

Type Attribute screens?

Most of NOAA TAS's are either annual or multi-year - which will

require new setup each BFY. That said, each year will require a
mapping of Program Codes to the CAT B Reporting Codes. There is
going to be much difficulty for NOAA to map hundreds of Program
Codes to many multiple CAT B Reporting Codes. Will there be a Tool
to automate this process?

NOAA will need a Tool to automate this process.

What is the connection or difference between the Trading Partner

Agency Identifier (middle of screenshot) and the Trading Partner (in
the additional information box)?

Is there a way for the TP Main account to be reported on a JV?

Can you please show the window when selecting the parentheses ()
on slide 13 for the JV entry attributes (the right most column)? We
would like to see all the available attributes to get a better
understanding of the available options.

Not a Question - Just an FYI: If there are ever new codes that are
needed for DATA Act or if something does not match - CSC does go
to the Budget Office to ask which codes to use.

Not a Question - Just an FYI:

There can be great complexity creating a BEGBAL GTAS Trial Balance
(post-close balances) for the new fiscal year derived from the prior
fiscal years Period 12 GTAS pre-closing balances. We need to see a
walkthrough of this process as our TAS structures are complex and
include many different GTAS attributes.

Can you please provide the GTAS report that can be generated by
Fund Value in EBS? We also are requesting to view all reporting that
is available to us.
You mentioned we will have a standardized closing process. Will
bureaus be able to close on a different schedule and reopen if they
need to? I thought the answer was yes, is that still the thinking?

What controls are there when two GL periods will be running

concurrently (meaning GL module opening for two periods)?

Are Financial Statements considered a standard report for this

instance?

Can you tell us more about Federal Financials as a module?

We understood from earlier briefings that there were 13 periods

that needed to be opened/closed. The FV module slide indicates
there are no periods to open/close. Can you explain the difference?

What is meant by non-transferred activity?

How will the automatic running of the Create accounting program

impact the other transactions being run during the day?

If this is a batch process multiple times a day how does that result in
providing real time information? Do the accountants need to
periodically check for the results of this report?
Does this assume that there is no shut down period and that users
can stay in the system as the create accounting process runs?

Does this address the processing of JVs at the GL or sub ledger and
what are the implications to the timing? (Meaning do all subledgers
have to be closed to ensure the GL is accurate before making JVs to
the closed accounting period within the context of the next
accounting period? )

What are the implications if the PA module is being used?

Is this how we process on top adjustments after sub ledgers are

closed?

Does unposted AR and AP mean it is in the system but we don't

know how to assign the accounting to get it to post?
Is the description field where the reason why the invoice is on hold is
explained?

How is the Budgetary Execution Transaction Register Report going to

be used?

Are these reports available in excel?

Is the month end close process a single department-wide instance or
split between NIST, NOAA, and Census?

How long is it anticipated for the close process to take?

Will the close of these three bureaus be done in a coordinated

sequence/order or can it be done simultaneously at each bureau?

Based on the screenshots it appears the period numbering starts

with 2 for October. What is period 1? Is it possible to use the same
period numbering schema as Treasury (and the fiscal year) to ensure
consistency when referring to data (ex, OCT = 01, NOV = 02, etc.)

Will NIST have the ability to close its cross serviced customer
bureaus separately? (ITA is sometimes closed later than other
customer bureaus.)
ITA's month-end State Department files are not available until the
first business day after the month. These files can have upwards of
$200,000 in paid accruals in them, should they include a newly
disbursed payroll. Sometimes more when there are large LES
(Locally Engaged Staff) separation payments. Not getting these files
posted to the proper accounting period results in Treasury Cash
reconciliation challenges and Treasury statements of cash
differences.

Year-End:
Does EBS have a close per bureau capability to allow NIST and ITA to
stay open longer than other bureaus may need to be? We currently
close three times at year-end, customer bureaus, NIST and ITA.

NIST processes the deferred income memo after the customer

bureaus' close for the YE closing for NIST, then wait for the ITA State
files and closing to complete the year-end stage 1 close. Ideally,
NIST and ITA would need to stay open longer such that other
bureaus can be closed more timely.

How will EBS generate it's Estimated Labor Accrual? The Estimated
Labor Accrual is a payroll estimate until month-end for labor that is
expected to be incurred, which can be a one day estimate or close to
two pay period estimate.

NIST currently utilizes two methods with out of the box CBS.
1) An estimate based upon the last pay period, which is used by all
non-NIST customers.
2) An estimate based upon entries in Web TA, which is more precise
and preferred by NIST for NIST. This is the NFC200 process that is
referenced in the RFP as a NIST required interface.

Is there a possibility to generate a labor obligation similar to the

Estimated Labor Accrual for payroll that is to be incurred in future
months? This could be a feature to use on a quarterly basis to help
manage solvency to the quarterly apportionment, and may be most
beneficial in Q4.

For example, if we're closing August and generating an Estimate

Labor Accrual for August, could there also be a labor obligation (or
commitment) generated for labor expected for September?

Meeting this requirement might pay dividends as it should reduce

the need for solvency applications like NIST's MyTools application,
maximizing the BAS investment's benefit.
NIST has approximately 30 different SLT interfaces that require an
efficient means of interfacing/import in EBS and depend on a project
code capability (as noted in our risk).

Question:
Is the Web ADI functionality being updated to include a project code
capability? If not what is the solution?

Potential Impact:
Without this efficiency NIST will not be about to conduct a timely
close (and numerous downstream impacts).

In addition NIST will not be able to meet the Congressional

requirements for managing the NIST WCF (and similarly for our
customer bureau's needs). -- As previously shared: the NIST
Working Capital Fund (WCF) was established in the Deficiency
Appropriation Act of 1950 (64 Stat. 275, 279, Pub. L. No. 81-583),
providing the agency a way to (a)fund the cost of providing services
and information to other agencies and the public, (b) efficiently
distribute costs that should be shared by all sources of support, and
(c) invest in equipment and inventories. -

How will cost allocation be run for NIST? Will it be based upon total
obligations?

What will the EBS process for Over/Under (CM202 - BEA and NTIA)
cost allocation and surcharge (CM204 -NTIA, NIST, BEA and NTIS)
methods? Both allocations are currently being performed during the
month-end close.

Are the trial balance reports available in both report and download
(Excel) format?

Will Tableau have a real-time trial balance reporting capability? - If

any table is to be real time in Tableau, trial would be a prime
candidate.

NIST does have some real-time reporting capabilities which we've

accomplished with data views and also with Data Guard "log
shipping" to separate any reporting vs. transactional risks with Trial.

NIST currently runs WIP (unbilled to billed receivables) during the

month-end close. Will this take place during the month-end close in
EBS environment?
NIST is used to seeing accounting information/Project task on the
reports. Will the subledger unaccounted reports be modified to add
accounting information - ACS,Project/Task information?
Also, how would the NIST user be able to run these reports to see
bureau specific information? These reports seem to be at the
DOC_LEDGER level.

Subledger period close exception reports - how would the NIST user
be able to run these reports to see bureau specific information?
These reports seem to be at the DOC_LEDGER level.
How can the system ensure that Create Accounting program does
not pick non-transferred activity of other bureaus while they are
working on the corrections and are not ready to transfer yet?

Assuming that the BAS core financials is down during the close
process for any data entry,
1) what is the approx time the system will be down until after all the
bureaus are completed?
2) Will the users not have access to their responsibilities to avoid any
data entry transactions? How will the data entry be prevented?

Frank Cooley (NIST AR) (asked in the chat) about the bureau users
access to Oracle DB to run any queries. Will bureau users have
access to any instance of Oracle DB to run SQLs?

How will additional vendors or suppliers be added separate from

SAM such as grantees (i.e. students)?

It appears that SAM data will be stored in both the FedAdmin and AP
modules in EBS. What is the significance and/or reason to have this
data in both modules?

If PRISM has a new supplier, how will new suppliers be added to the
AP module? Is it automated or manual?

With a single instance for shared SAM data how can suppliers or
vendors specific to a bureau be identified?
What portion of supplier maintenance will be delegated to bureaus
vs. the departmental responsibility for administering common SAM
components (i.e. vendor number)?

What will be the key field to identify suppliers and any sub suppliers
information? What fields will be used to match to CBS vendor
(supplier) data to support migration of open documents from CBS to
EBS?
Please clarify what the "On Demand" connection is. Is it for selected
vendors or the entire set?
Please describe the expected behavior of SAM to GEMS and then to
EBS for grants related transactions?
What is the unique entity identifier for looking up the SAM
registrations? Tax ID, DUN, Supplier name, etc. And what is the
frequency for the refresh?

How is the supplier number being created for both SAM and non
SAM suppliers in the AP module? Are they system or user generated,
or a combination?

What is the BAS recommendation on configuring the supplier

number field, manual or automated? NOAA believes, based on the
large number of types of suppliers and potential PII ramifications (if a
SSN/TIN/EIN is used), that an automated supplier numbering
approach is best.

What portion of supplier maintenance will be delegated to bureaus

vs. the departmental responsibility for administering common SAM
components?

This question is also relevant to the management of the DNP, in

terms of deactivating the supplier so this may not be best performed
at a department level.

What is the process for managing supplier status'?

When we go to pay this supplier, will that (DNP) be checked again

before the payment is advanced?

Will the bureau/EBS be notified if the payment from PAM should not
go out?

What is matching to SAM based on TIN? DUNS? CAGE?

There are vendors who do not have a TIN, (i.e. foreign vendors and
federal entities) how will these records be handled?

NOAA is required to report on Foreign Assistance showing the

Benefitting Country / Region. Some vendors may be categorized as a
Foreign vendor but have US addresses for purchasing and/or
payments. How will the Benefitting Country / Region be identified
and maintained in BAS?

Will there be a mechanism to identify suppliers as foreign entities

that is separate from having multiple addresses?

Will there be a separate legal entity ID for NOAA serviced bureaus

(EDA, BIS)?
Can you describe what purchasing and pay means?

Are the Address Purpose check boxes populated by SAM or are they
checked manually?
For foreign suppliers, how will their remittance information be
managed if their SAM information is incomplete (necessary banking
information is missing and the "SAM Supplier" checkbox is checked,
locking the record for edit)?

Will all other pay.gov transactions be interfaced into EBS and not just
Seafood Inspection?

How is batch defined in this situation?

If we have multiple batches of CC payments are we putting one BIG

batch together? Each batch has a different deposit ticket voucher
number, so how will that work in EBS? Combining batches (with
different deposit ticket numbers) will cause a significant
reconciliation problem.

Will there be two ALC’s like today?

Previously we understood there would be one ALC per bureau is that

the case or will we stay as we are today?

When selecting the vendor, when are the other terms such as 1099,
Discount Terms and Conditions etc. checked in the award process
flow?

Where open documents are migrated from legacy C.Suite and CBS
into PRISM and EBS, what is the expected behavior for converted
open documents in PRISM as they are interfaced? How will those
work?

Will invoices, receipts, acceptance as a four-way match all go

through PRISM to EBS?
Is the expectation that this functionality will be available on Day 1?
What if any invoicing will occur in the Invoice Processing Platform
(IPP)?

What is the Delivery/Funding ID field in the Funding screen?

Please provide all the types of checks and validations that will occur.
What are the error messages that will be provided? Examples of
checks include funding against commitments, Vendor Terms &
Conditions, mods where dollars are accrued against change orders
etc.

While we know you mentioned this would be provided during testing

and training, it would be helpful if some examples could be provided
before then to ensure the bureaus have a full understanding of the
process.

Is there a process for "closing" out an award (i.e., not the same as
deobligating)?

How are "cancelled funds" processed from EBS to PRISM?

Will additional charges, if the invoice is processed later (Object Class

43), also be displayed on the "Invoice and Payment" section of
PRISM?
How is it possible to see the source document (requisition or order)
if needed in EBS?

We have situations, where we have notice of assignment - where the

contract is with one vendor (usually a bank) and have been
authorized to pay.

We understand that Notice of Assignment can be handled in EBS.

Could you please explain how a "Notice of Assignment" for a vendor
would work and what is the tax implication (i.e. assigning payment to
another vendor like a bank)? How does EBS issue the 1099 in this
scenario? Could you please provide screen shots or a walkthrough at
an upcoming session?

The change from supply to service would be a financial event. If

transactions are expected to start in PRISM, if you are changing the
"type" wouldn't you need to have a modification in PRISM to change
from supply to service since PRISM is the system of record?
During the CS sessions we were asked to provide examples of types
of reporting we would like to see during another walkthrough/CS
meeting.

Here are some of the types of reports we would like to see (this is
not an all inclusive list) - detailed level reporting would be helpful:
- Commitments that have not been converted to obligations
- Obligations that need to be closed out (we are required to process
quarterly certification of obligations to get obligations off the books
- Transactions that have not received final approval
- Pending transactions

How will TBM be accommodated in PRISM? What are the plans to

enable integration between PRISM and EBS for TBM (Technology
Business Management)?

It would be helpful to understand when the details of TBM will be

discussed and in what Sprint.

I am interested in knowing a little bit more about how other non-

SAM data information, such as employees' information, interfaces
with Supplier Management.

The 1099 and 1042 box have been mentioned during presentation.
Hope we can see them in Supplier site in the next training.

How do we transfer all non-SAM existing records from CBS to BAS?

Who should initiate a non-SAM record in BAS?
Will Supplier data in PRISM be directly linked with EBS AP
workbench?
Are there two distinct data tables - one for vendor and one for
customers or is there a relationship?
Can vendor be used to refund a customer overpayment if they are
already in the vendor table (as a SAM vendor or non-SAM vendor?

Will SAM supplier updates flow through PRISM and EBS or just EBS?
Could you please explain why there is on demand refresh to PRISM
and daily for EBS. Will PRISM and EBS not be out of sync in terms of
Supplier information. How are these discrepancies between PRISM
and EBS handled?

How can the supplier search be used to search by unique supplier

fields - like DUNS number before creating a new supplier? This will
help the user to create a non SAM supplier by mistake if there is one
already existing one in the EBS system. It appears that search is for
just SAM vendors.

Are both Bill to and Ship to locations synced with PRISM Bill to Ship
to locations? or is this maintained only in EBS? Please clarify. It
would be helpful if you can provide corresponding fields/screenshots
in PRISM.

For each bureau, each payment/purchasing site configuration is at

the Vendor sites. Will each vendor site have a bureau specific string?
How will the non-SAM vendors accounting be configured for each
bureaus? Are there any cross validation rules that does not allow
e.g., a NIST user to not pick a NOAA accounting string?

It was mentioned briefly in previous PTR meetings that the year-end

close process will occur for all the bureaus department-wide at the
same time. Can you please confirm that all bureaus are still closing at
the same time, and if so, what happens if a bureau cannot close for
some reason?

There was a mention of "multiple preliminary year-end closings".

Can you run the multiple Precloses separately (Preview and the
Final) at the bureau level at any time or will those be processed and
coordinated across DOC at the same time too?

The "mock" Precloses will really need to be performed as many

times as needed at the Bureau level.
NOAA has a three step closing process (Stage 1, Stage 2, Stage 3
(final)). We specify whether there is a Stage 1 or Stage 2 close and
we apply priorities with specific TCs.

From the Common Solution meeting we understand there is a two-

step closing process. However we were unsure if a bureau can re-run
the Preclose - Final process. If you run a Preclose - Final and then
need to perform on-top adjustments can you rerun a Preclose -
Final?

Is Sequence Number in EBS the same as the Priority Order in CBS?

Will the source requisition documents (e.g., those from PRISM)

reflect the cancellations of a requisition in EBS in the source system
(e.g., PRISM)?

Will the actual documents get cancelled out in the source system or
does the user need to take an action in the source system?

Decommitments will happen in the GL, but will those

decommitments be reflected in the source system?

Will all bureaus have the same cutoff date in source systems (e.g.,
PRISM, E2, GEMS etc.) prior to the year-end close or can each bureau
have their own cutoff date like the bureaus do today?

What would happen if an on top adjustment needs to be made in

early November after a final year-end Close has occurred? This can
occur because of the audits that are going on during this timeframe.
How can that be accommodated in EBS?

In EBS, we need to ensure there is a close at the GTAS attribute level

and the trial balance level.

Does the Year-End Closing Execution Report also take into account
Attributes such as Category (e.g.,4871 to 4801 - where we would
need to know whether it is Category A and/or B etc.) If there are
both Category A and B how would we know whether it needs to
close into a certain account?
Where does Hyperion fit into the Year-End Closing process? Is it in
the preclosing or closing process?

Each reporting Bureau will require a crosswalk for EBS data to

Hyperion Financial Management (HFM) Format (or whatever system
OFM is using at that time) for the quarterly CFO Act Financial
Statements.

NOTE: For NOAA’s Go-Live, this tool for crosswalking EBS data to
Hyperion is not required until Period 3 (Q1) FY 2023 reporting.

We understand from the Common Solution meeting there are 14

periods in a year. Our understanding is that you can have for
example FY20 and FY21 open at the same time. Can you please
explain more about what occurs in periods 13, 14 and 1?

Can EBS be restricted to who can have access to the open FY and
who can post transactions when both fiscal years are open?

It was mentioned during the Common Solution Meeting there is a

"Year-End Workbook/Plan". Is that something EBS generates or will
it be determined by DOC? Is something like task code rollover into
the following fiscal year included in the "Year-End Workbook/Plan"?
When will we discuss all the Year-End activities for closing? For
Budget Execution, this is important because we need to understand
Project and Task Code Rollover etc. NOAA has a detailed year end
plan for closing which we can provide for reference.

Is the Year-End (YE) closing execution report available in a CSV or

Excel format?

We have heard that "You will not need to address any issues with
data integration." Does that mean if, for example, there are any
authorization/voucher files that are not processed by the EBS
solution or require re-staging, this will be addressed at a DOC
level/nonbureau level?

The current NFC employee load process automatically creates the

employee's employee record and vendor record. Census has
Decennial employees that are loaded that create the employee's
vendor record only. The same process creates the E2 traveler
profile. We heard that references employee setup will be part of the
SOPs as new employee onbording. Will NFC and Decennial
employees be required to exist in a separate employee table (similar
to CBS GL029) or just identified in the supplier table (similar to
PM002) as an employee?
Can we see a future year trip scenario in EBS? (a) It's not clear how a
future year trip is entered in E2 and "held" and tracked until the new
budget year in EBS. (b) Are there any controls in EBS that will
prevent the a budget year ACS from being used if the travel does not
fall within that period?

Census has the need to send at least current year, one year prior,
and one future year of POET to E2. This is most important at the
beginning and end of a year but adjustments to trips can be made
throughout the year as well.
Would there be the option of adding an additional "Audit" step
between CWT/E2 and Payables, if desired?

CBA integrates automatically: During the teams meeting on 5/18/21,

it was mentioned that DOC will receive one CBA file for the entire
agency. We're currently receiving reconciled monthly CBA file(s) for
each account that are assigned to NIST and customer bureaus for
both transactions that were booked through E2 and/or directly with
TMC agents. Are we continuing to receive these files in the same
manner, or we must extract our data to exclude NOAA and CENSUS
data from the master file? We also want to know how EBS solution
would handle CBA transactions that are booked outside of the E2
system for relocation travel or cross serving bureaus without E2 trip
ID. Our CBS is currently auto assigning the 16 digits CC number as
invoice number to avoid the keying error. Does EBS has a similar
process to validate the CC number, header amount, object class
code...? Are we going to have CBA integrate auto process without
the user having to download the file(s), click process, correcting the
error and post transaction in financial system? How do EBS handle
the change of tickets outside of E2 creating a higher ticket cost, fees
charge exceeding the tolerance amount that require an amendment,
but funds has expired at 9/30 (trip is for Sept and gets billed in Oct)?
In addition, we manually process a payment for CBA accounts that
are used for hotel/rental car expenses; is it possible to enhance this
process to automatically process?

Is it true that for IBA payment, the E2 will perform the system audit
between travel authorization, voucher, and receipt to avoid a
duplicate and/or un-authorized claim that could generate an
erroneous payment prior to approve by approving official?

Would we be able to reject an individual transaction and not an

entire batch if we can't post it due to invalid/inactive ACCS, expense
amount exceed the allowance tolerance, inactive employee number,
funds expire...who will be responsible to fixing the transaction and
where should they fix it from?
Would a traveler be able to request travel advance inside of E2
system and auto post in EBS for transaction types: ACH, wire
transfer, Treasury check and convenience check? The convenience
check currently handles by individual bureau convenience check
writer and funds are drawn against the Pcard.

Please add these items to next Travel Deep Dive section. We have
lots of challenge with this process and so many workarounds. We’re
hoping the new EBS will enhance this process to be more efficiently
and save time.

Please add this item to next Travel Deep Dive section. How would
EBS handle a pre-pay voucher for TDY travel or split year travel to
draw down the partial UDO and still leave the remainder UDO line
item open for a final voucher? Do we have an option to do mass
close UDO to clean up old travel transaction?

Please add this item to next Travel Deep Dive section. Are we going
to have two separate tolerance setting in both systems or one
setting applies to both? We currently have so many challenges with
two settings that are not synchronized and hoping for better
enhancement with EBS solution.

I believe the relocation system Deep Dive section will be scheduled

in Sprint 4. Since NIST/NOAA is using the same system and NOAA will
go live first, is it possible if NIST can go live at the same time with
NOAA? If not, we might need dual systems running and that would
potentially increase in the license fees cost, admin fees....How will
EBS handle relocation payment is processed by State Dept, but the
obligation is setup by NIST and an accrued expense will be
automatically drawn down the obligation amount?

A scenario that we would like to have tested is that in which the

funds balance is at $100. A requisition is created for $100. Payroll is
posted for $50, assuming this is advisory. At this point, funds
balance is ($50). Attempt to obligate the req for $100. We are
expecting that this will fail as the sgl entries will be D to 4700 and
4610 and credit to 4610 and 4801. It was indicated in the meeting
that the obligation would pass funds check.

Census would like to express that we do not believe that BFY should
not be tied to the project or task. We currently identify and key in
the fcfy(equivalent to BFY) with each transaction and do not believe
that it should be tied and therefore require new creation for each fy
of either the task or project. It should be an independent attribute.
Validation of the use of project and task should be done against the
start and end dates of those values.
Would like some additional information based on a previous meeting
where it was indicated that for no year funds, non obligated funds
would not take on a new BFY but would require that funding to
retain the originating BFY. Is there another way to track the original
fy source of funding, meaning that the funds would still roll over and
a user would be using current BFY but BAS would track FIFO where
the funding originated from?

Projects cannot start with Zero. Existing CFS projects already begin
with a zero. Adding a bureau code to the front of the project, would
be an option to resolve this.
Project must be unique across EBS system. Should a bureau code
value be assigned to the project code?
Limiting the Task Code to 3 characters may be limiting. Longer task
codes may allow future flexibility.

NIST's existing business process is to have a division code in the

project code. Should this be required going forward? Will be
required for data conversion to start.

Can BFY be set at a project level, instead of at the task level? Or

would it be best to map the CFS project to the EBS task code? And
CFS task code to the EBS project?
Should BFY be appended to the front of the task code, making it a 5
digit number? This might help our customers choose the correct
POET, which drives the BFY.

NIST Internal: need to confirm who's setting up projects and the

burden multipliers. - Challenge if burden is setup incorrectly

What is the workflow for approval routing? Need to assure Budget

Offices have approval to confirm the burden setup
Can task code have specific burdens too?

Can a project be selectively limited to one funding source? We only

have a select few instances where it would make sense to have a
project funded by multiple funding sources (e.g. NIST G&B, ITA
Deposit Fund).

Having a project's funding source from multiple funds introduces

news risks and will require new controls (manual?) to manage, which
we'd like to avoid.
Will the project code metadata, e.g. NSF code, Goal Code, Budget
Initiate, etc. be tracked at the Project level and/or Task level, given
multiple funding sources for the tasks?

This may be another reason to only very selectively allow a project to

have more than one funding source.

DoS financial system allows a max of only 8 characters and other

feeder systems could have limitations too. We should be careful to
vet the proper length of the project code to not create other
downstream issues.

If 10 characters,then we could have a 2 digit bureau code + 7 digit

project + 1 for future use. That could work with State, as the 2 digit
bureau code can be inferred from elsewhere.

A large percentage of NIST's tasks are "000", the default task code. If
we allow a project to have more than on funding source, there's a
high likelihood that a person could choose the incorrect task code.

For example:
* Fund Source A, Task 21000, Project 1
* Fund Source B, Task 21000, Project 2
* Fund Source B, Task 21000, Project 1

I'm imaging a pick list of many "21000" tasks all with different
funding sources, and Budget personnel, NIST Data Control, NIST AOs,
ITA, etc. all having to select the correct task code, and carefully
check the funding source. Seems like a significant risk of selecting
the wrong Task and therefore funding source, which could result in a
misuse of funds, new management controls, etc.

Will there be an automated way to rollover task codes (and project

codes if required) from year to year?

* We noticed that other agencies that use EBS may already have
automated processes (Bots) that do this.
* See the GSA Bot Use Case Inventory:
https://digital.gov/guides/rpa/rpa-use-case-inventory/

What is the concept of operations regarding who will be entering the

setup of Project/Tasks and will DoC/CSC have oversight of this
activity to ensure bureaus follow the agreed upon business process?

Is the recommendation to always enter the ending date for Trans

Duration field? NIST currently leaves CM004 Project end date field
blank.
Is the current CBS concept of Project Type needed in EBS? CBS
Project Type currently impacts TC entries and reporting.

Once active / approved, what fields on project / task can no longer

be changed? Is it possible to make corrections if mis-keyed in BAS?
(If just to some fields, which ones please?)
tions and Answers
Answer

In June, July, and August 2020, there will be functional workshops with bureaus and service customer representatives to elicit
needs and requests for each of the workflows, including Acquisition. Regular feedback resulting from these workshops and the
subsequent Global Design activities will be provided through multiple communication channels - both face-to-face and throug
BAS website. The Acquisition software (Unison PRISM) does not manage the Asset Management piece. Asset Management wi
in Sunflower.

Yes, it will be. Unison PRISM will serve as the contracts tool for the Acquisition Procure-to-Pay end-to-end process. Unison PRI
provides records management for supporting documentation of individual contract awards. This capability will be reviewed in
detail during the Unison PRISM Workshop (scheduled 6/26/2020) and into additional discussions during Common Solution.

Business Applications Solution

BASProject@doc.gov
Slides for all of Town Halls and Table Talk meetings will be available on the website and sent via email to participants. Slides ca
be shared via email. We will start attaching the slide deck for these events with the invitation as well.

You can find more information at the official BAS Program Website - https://www.commerce.gov/ofm/bas-homepage/busines

The BAS program timeline encompasses three implementation phases. In the first phase, ALL DOC bureaus will be participatin
up-front system decisions including data standardization, architecture (solution) design, system configuration and set up, EDW
design and build, and business process reengineering. During the first 18 months, the BAS Team will be developing the Global
and Common Solutions. There will then be a three-phased implementation plan as follows:
i. Phase I – NOAA, BIS, and EDA (Q3 FY 2020 – Q4 FY 2022); Go-live October 1, 2022 (includes Global Design and Common Solu
ii. Phase II – NIST, NTIA, OS, ITA, FirstNet, OIG, BEA, ESA, MBDA (Q1 FY 2023 – Q4 FY 2023); Go-live October 1, 2023
iii. Phase III – Census (Q1 FY 2024 – Q4 FY 2024; Go-live October 1, 2024)
The team will need time to complete Global Design and a Common Solution for all bureaus before beginning the NOAA
implementation activities. Given the scope of BAS, we anticipate that the October 2022 date for a NOAA implementation is re

The Business Applications Solution (BAS) program is a Department of Commerce modernization initiative to deploy an integrat
suite of financial and business management applications in support of the mission. The objectives include implementing and
integrating a suite of commercial off-the-shelf (COTS) business systems, Enterprise Data Warehouse (EDW) and Business Intell
(BI) reporting solution, and system interfaces in a hosted environment. The BAS program will continue the ongoing emphasis o
achieving organizational excellence and outstanding customer service for the Department.

The BAS PMO Team is responsible for developing the O&M strategy and detailed standard operating procedures (SOPs) for po
deployment support. As part of the O&M strategy, the BAS PMO will define overall O&M support with the input from bureau
participants. O&M support will align to the DOC "one set of configurations" approach. The O&M plan will include details relate
help desk support, release management, as well as the SOPs for subledger activity, month-end close, year-end close, and
configuration management.
BAS is an IT modernization effort aimed at implementing commercial off-the-shelf solutions for Financial Management, Acquis
Management, Asset Management (real, personal, and fleet management) and an enterprise-wide standard data warehouse. A
bureaus are in scope for BAS except USPTO. NOAA will transition with their service bureaus and NIST will transition with their
bureaus. Census will be transitioning by themselves. USPTO will not use the Core capability but their data will transition into th
EDW.

FY 2020: 10 positions are budgeted and will be selected soon. There will be a total of 45 PMO/ SME positions that will be avail
Detail positions will begin in FY 2021. The BAS PMO is currently working on the statement of work for these positions and will
reaching out to the bureaus for SME recommendations. The BAS PMO is also looking at part-time resources to participate in
workshops, etc. The BAS PMO is aware of restrictions in time commitments.

On April 24, 2020, the Department of Commerce awarded the BAS contract to Accenture Federal Services (AFS). AFS will provi
implementation services, project management services, and hosting/support services and will be working with the BAS Progra
Management Office to deploy the integrated suite of IT solutions.

The BAS Program provides many benefits for the Department of Commerce, including:
Improved data quality and full data transparency:
- Centralized, standardized enterprise-wide data and enhanced data analytics and BI
Timely and accurate reporting to internal and external stakeholders:
- Department-wide system, consolidated EDW, and access for management decision-making
Operational efficiencies and reduced total cost of ownership and risk:
- Commercial, cloud-based software-as-a-Service (SaaS) with standardized configurations, single Department instance, stream
business practices, and enhanced user experience

Core Applications team includes some Out-Of-The-Box (OOTB) report capabilities. Reporting needs beyond these OOTB report
being captured in the CS Outcomes Tracker and relayed to the EDW team to evaluate the impact and identify a solution.

Yes. The BAS solution set will have a single accounting structure - details will be determined during Common Solution.

At this time, budgeting is out of scope for BAS. There are several programs that can be used to create budgets that can be inpu
Oracle. The Budget formulation will continue to follow the way DOC does today; however, Oracle will have framework to supp
budget entry.
The workshops and discussions include invited representatives/SMEs from across the community to interactively gather inform
about current operations and elicit pain points. In order to receive summary information from these workshops, or to request
participation in any of the workshops, contact the BAS PMO at BASProject@doc.gov.

DOC will leverage the existing Grants systems (GOL, OPCS, GMIS) and integrate them with BAS for both financial transactions a
reporting. Meanwhile, the GEMS team, which is separate from BAS, will continue their work. GEMS is not included as part of t
program (it is a separate effort) but the BAS Team is working closely with the GEMS PMO to integrate with their implementati
Right now the BAS Team is planning on ingesting data from current Grants systems. The BAS Team will leverage the existing G
systems (GOL, OPCS, GMIS) and integrate them with BAS for both financial transactions and reporting. Long term grants will b
accounted for in Oracle.

The requirement for translating current roles into BAS roles and responsibilities and determining appropriate access control is
captured in the Outcomes Tracker. The identification and translation of BAS roles and responsibilities informs the training nee
BAS users. Access controls will be addressed as part of Security Controls.

BAS will focus on all reporting components for real property. Current reporting requirements will be met by a fusion of core
applications and EDW functionality. DOC will have access to Sunflower's standard reports. DOC is in the process of implementi
Sunflower Analytics, Business Intelligence (BI) offering, that will have access to the Real property data set. In accordance with
BAS EDW schedule, Sunflower Real Property will intergrade with BAS EDW to provide expanded reporting capabilities.
Sunflower will receive a refresh and will be re-deployed in a single configuration for the agency. Individual workshops will con
gathering and discussing more information about Sunflower requirements. Sunflower for real property will go live before othe
systems and necessary integration points required between Sunflower and BAS Core Financial Application (Oracle EBS) will be
during Common Solution. Personal Property is an essential part of BAS. Fleet property will follow. Personal property will be
implementing a fresh instance of Sunflower, deployed in a single configuration for the department. If you refer to the CS high
Sprint Calendar, the Personal Property and Fleet discussions will begin in May 2021. The Personal Property and Fleet work stre
will deploy into Sunflower on the same schedule as Core Finance and Acquisitions:
-Phase 1 (NOAA and serviced customers): 10/1/22
-Phase 2 (NIST and serviced customers): 10/1/23
-Phase 3 (Census): 10/1/24

The new application will be web-based but not accessible to the general public. DOC may utilize several encryption technolog
including VPN to secure the data end-to-end. The BAS Team is working to determine the detailed security plan over the next c
of months after reviewing and analyzing: the design, system, FedRAMP, NIST security and privacy requirements. Account crea
and management responsibilities will be handled jointly across Accenture Federal Services (AFS) and BAS. Clear delineation of
responsibilities and procedures will be determined as the program progresses. At this point, specific access controls, such as th
of CAC/PIV cards, have not been decided.

The DOC BAS PMO affirms the one configuration / one solution approach agreed upon by the Department and will work with t
Decision Making Forum to resolve any open discussions related to Bureau requests for customization.

The DOC BAS PMO affirms the one configuration / one solution approach agreed upon by the Department. During meetings,
workshops, and other discussions, the event leads will use the Met, Mod, Move On approach to determine if the disagreemen
be resolved quickly. If agreement cannot be reached at the time, the disagreement is formally noted in the Outcomes Tracker
discussed during future discussions. AFS escalates these unresolved disagreements as risks/priorities to DOC BAS PMO weekly
their awareness. Ultimate resolution of unresolved disagreements will be addressed by the Decision Making Forum.

DOC BAS PMO will work with the Decision Making Forum to review and provide sign off on the final requirements, using a pro
that will be discussed with and agreed upon by Department executives. The DOC BAS PMO affirms the one configuration / one
solution approach agreed upon by the Department and will work with the Decision Making Forum to resolve any open discuss
related to DOC requirements amongst the bureaus.

During Global Design, the BAS Team will be working to come to consensus on common configurations. If there are features th
cannot be accommodated, a new business process will be developed or the feature will be documented on a backlog for futur
enterprise configuration. Demos and an overview will be part of Global Design.

A single set of books for Commerce is our goal. Standardization of data elements will occur during Global Design and into Com
Solution. Common Solution will standardize not just the structure but the values, which is important for conversion.

Based on review and evaluation of several formally proposed solutions, DOC entered into a contract to implement the followin
applications
- Unison PRISM application for acquisition capabilities
- Sunflower application for Real, Personal, & Fleet property tracking
- Oracle EBS application for core financial capabilities
CBS and C. Suite will be retired; Sunflower platform will be refreshed; FRPM will be replaced as a property system and MARS
capability will be included in BAS. These and other feeder systems (approximately 200) will all be evaluated during Common S
to determine how they will be handled.

During CS, we are reviewing the configurations and requirements to confirm the overall solution. The AFS team will create a te
strategy to validate the DOC configurations and requirements. Based on the outcomes of the Common Solution and additiona
deployments, a Test Control Cycle Sheet will be created to outline all the business user stories that will be tested. Test scripts
created from these, allowing the DOC community to validate the to-be business processes. Detailed instructions, assignments
target dates will be provided for the development of test scripts. The test scripts will navigate through the system following th
business processes and indicate the expected results for the DOC community to confirm if the test script confirms the DOC sol
(pass / fail). Each test script will be mapped to the requirements.

Testing Phase activities will align with each implementation/release schedule. Dedicated, targeted testing (e.g. Unit, Systems,
Integration, and Regression) will be performed by bureaus during their deployment year. The AFS team will communicate resu
this internal testing to the BAS PMO team, escalating any defects or issues. The User Acceptance Test will also be conducted d
the phased deployment years. We will rely on the DOC SMEs to support the User Acceptance Testing. Details in terms of testin
participation and related schedules will be announced as we near the deployment timeframes.

Training needs identified during Global Design and CS sessions will be captured and tracked in the Outcomes Tracker and relay
the Training Team to address during Training development.

Online training will be available for web-based introductory courses. Instructor-led training in a classroom setting is the prefer
method for navigational and role based training. This allows instructors to provide help throughout the training. The Training T
will work with Training Coordinators to plan the locations and times to accommodate users’ availability. If in-person training is
feasible, the team will look to conduct virtual instructor-led training as an option.

Accenture Federal Services (AFS) will do the initial training for the pre-deployment phase. The permanent solution for long ter
training post deployment is still being finalized.

Yes, BAS will support commitment accounting. From a process flow perspective, the requisition is created in PRISM and compl
funds validation in the Core Apps. If the funds check passes, then the requisition will be routed for approval. After approval, th
requisition is considered approved and the funds will be committed. This action will result in the commitment accounting in th
financial system based on the SLA posting model.

Yes, data from legacy CBS, C. Suite, property applications will be copied into the BAS EDW. During deployment planning, the B
EDW team will work with current system POCS to determine which database and tables will be copied into the EDW data lake

Currently the 1099 / 1042 requirements speak to generating those specific forms. A repository portal is currently not a part of
BAS core application framework; however, this can be considered in the future.

In AR, Interest and penalties can be assessed on overdue invoices and or late payments. These can be at a fixed amount, rate o
other schedules. These charges can create invoices or debit memos, and these new transactions have their own payment term
(which may be independent of the original transaction). Therefore, all the rules related to penalties and interest have to be de
and assigned to customers.
BAS requirements include integrations with PAM. Currently the BAS team is also assessing the requirements for an e-invoice
solution. As part of that analysis, we will confirm capabilities related to offset research. We will provide more information rela
that as part of Sprint 3 and Sprint 4 related to the offset capabilities.

This topic was covered in part during the Projects 101 session on 12/8/2020.  The ACS segment values will be captured on eac
Project/Task.  When a Project/Task is entered on a spend transaction (Requisition, Purchase Order, AP Invoice), the full accoun
string is derived from the values entered on the Project/Task.  We are currently looking into the options for labor costs (T&A).
Allocation (and the WebTV) is scheduled for discussion on 12/15/2020.

Project and Task will be an integral part of the transaction flow. Project and Tasks will be part of the integration flow from EBS
PRISM <> Sunflower.

The BAS EDW will only include reservation data that is linked in E2. Reservation data that is not linked in E2 ( e.g., only exists i
CWT/Sato) will not be included in the BAS EDW at this time. Power Users will have the ability to upload data into Tableau (BI
reporting and data visualization tool), where needed, to enhance the BAS EDW data sets to support analytics and reporting.
Additional data sets will be evaluated

Open transactions from C. Suite will be migrated to PRISM. All other legacy data from C. Suite will be archived into EDW for po
reporting needs.
The EDW BI Reporting & Analytics application will be organized by business function-based communities (e.g. Finance, Budget
Within the communities, Power Users will be able to create and publish reports for their communities. It is anticipated that th
will be Power Users identified from the Department, Bureaus, and Line/Lab/Program offices.

The Sprint 1 process flows have been shared with DOC BAS PMO, and they will be reviewed as part of Sprint 1 CVS with DMF.
Sprint will focus on different process flows. Data dictionaries will be a component of the EDW.

This was covered during the Projects 101 session on 12/8/2020.  The ACS segment values will be captured on each Project/Tas
When a Project/Task is entered on a spend transaction (Requisition, Purchase Order, AP Invoice), the full accounting string is d
from the values entered on the Project/Task.  SLA configuration will derive the GL postings (DR/CR pairs), using the derived AC
string.  Accounting is posted from different subledger modules (Projects, Purchasing, Payables, Receivables) depending on the
transaction and the rules that are configured.

The KDDs have been shared on the BAS PMO website. The Risk Register is available on request; please email the BAS Risk Lead
(Rakesh Raman) - rraman@doc.gov.

This update to standard contract language would need to be confirmed by the acquisition office. In terms of how this relates t
BAS efforts, the e-invoicing portal is currently being reviewed by the BAS team. The recommendation will be discussed in thor
during Sprint 3.

PRISM offers the ability to digitally sign PDFs and awards in conjunction with a third-party signature tool. This requirement is
currently being discussed with the BAS PMO team. We will be discussing G-Invoicing in greater detail from Sprints 2- 4. BAS wi
support G-Invoicing capabilities.

Currently the BAS Core Apps team is reviewing the to-be recommendation for E-Invoicing which will be part of Sprint 3.
In terms of attachments, Oracle does support this. All attachments pertinent to the associated invoice can be attached and sto
within the system.

In terms of integration - the integration team is reviewing what data is included as part of the to-be data flow map. For examp
will receive SAM data to support PTP activities. PRISM will integrate with FPDSNG. The Acquisition records will integrate to EB
from a financial perspective.
PRISM, the BAS procurement solution, will contain similar data to what is leveraged in CSTARS today. It will be used as the con
writing system for the full procurement lifecycle, from acquisition planning to award closeout.

Current reporting applications (such as NIST Business Objects) will not be accessing legacy system data that is migrated to the
data lake. The NIST Business Objects application may still be connected to NIST CFS, Data Warehouse, C. Suite for a time after
BAS Phase 2 deployment; however these systems are not planned to be active long term after BAS is enabled for Phase 2 bure
BAS will work with current system POCs during their implementation preparation year (FY23 for NIST-managed applications) o
plan for decommission of current systems.

The project and task allow you to select specific values at the project or task level. This was covered during the Project Basics
discussion on 12/8/2020.

Project: BUREAU, ORG​

Task: FUND, BFY, PROG, ORG (defaulted from Project, but can be changed at the Task level).

If there needs to be restrictions of which bureaus or programs can use certain object classes, we can leverage Cross Validation
to only allow certain combinations of data. This was featured as part of our CVR discussions in November and recently on 12/1

Individuals will be able to identify delegation or proxy rules for workflow notifications and approvals of documents. This functi
allows the backup capability where the workflow will route that approval to the appropriate person. The support required for
updates for multiple workflows across more than one transaction will be discussed as part of O&M standard operating proced

We would need to see the business scenario. However, it seems that this could be achieved through burdening which will allo
surcharges and a fee % being pushed to a project. From there, you could create a cost allocation methodology and automatica
transfer the costs to different projects. The initial cost allocation session is scheduled for 12/15/2020.

Today, BAS Website is accessible from the Internet, and the users can learn about the program. Users are not required to be i
Commerce network. The decision to make the BAS program specific website accessible through internet or intranet past Oct 2
Go-Live is under review.

Those interested in working on the BAS PMO Project team should send an email to BASProject@doc.gov.

We will need to understand the timeline, but the expectation is that the same data will be available from NFC for BAS. We will
need to understand if this will apply to OIG only, or all NIST servicing bureaus. This is something that we will be digging into in
detail in Sprint 3.

Digital signature is currently being discussed with the BAS PMO team. However, PRISM is intended to support a paperless proc
Within PRISM, users will upload supporting documentation to a structured folder template that will serve as the electronic con
file. PRISM also offers a two-way message center on solicitations and awards for users to communicate electronically with ven
through Unison’s vendor portal, Fed Connect. These topics will be discussed further during the solicitation and award sessions
planned for Sprint 2.

Because the material contains proprietary information, it cannot be posted on mediums such as the BAS website. However, a
request for a copy of the materials can be sent to BASProject@doc.gov.
When we talk about invoices, this is handled by Oracle EBS as part of the procure to pay workstream in the Payables module.
and Payments module will have the corresponding financial accounting impact. As far as the e-invoicing functionality, the Core
team is currently reviewing the recommendation for the e-invoicing solution. This recommendation is scheduled for review as
the Sprint 3 timeline.

Yes. Both the pre-submitted Q&As and the write-in Q&As will be sent out via email and posted on the BAS Website in the Que
about BAS section (https://www.commerce.gov/ofm/bas-homepage/questions-about-bas)

EDW users will need to rewrite or create new reports in Tableau to obtain legacy system data (e.g., historical data from CBS, C
FRPM, and Legacy Sunflower that is not being converted into the BAS Core Applications) from the BAS data lake. Existing repo
can be used to create reports in Tableau. (Report SQL generated by legacy system reporting tools (e.g. Business Objects) may
to be modified slightly to remove any tool specific syntax.)

The discussions for these needed features will take place during the Common Solution phase which should take place beginnin
2021. The DOC BAS PMO will determine the features.

During the Common Solution discussions, which will begin in May 2021, requirements for Personal Property will be captured f
Personal Property representatives across each bureau. The goal is to understand the needs of each bureau regarding Personal
Property. These discussions will inform the development team how to best design a standardized solution that addresses the
identified needs.
The Risk Register is available on request; please email the BAS Risk Lead (Rakesh Raman) - rraman@doc.gov.

BAS supports document attachments that are related to specific transactions. There will be file size limits (network). Note that
BAS system is not meant to be a file share system like a SharePoint. For example, EBS will allow AP Invoice supporting informa
PRISM will be configured with a structured folder template that will serve as the electronic contract file for procurement actio
Users will upload related files, such as signed forms and proposals, to the electronic contract file in PRISM.

Auto Accounting is a method by which accounting can be derived for various Accounts receivable transactions. This is further
extended/enhanced by Sub ledger accounting. TCs are a CBS terminology. EBS will leverage the subledger accounting rules as
the auto accounting for specific modules.

We will schedule a data call and include this topic.

Correct - BAS EBS will be one instance for all activity. Oracle EBS AR functionality will support the one DOC solution and config
we will be deploying for all the bureaus. We will provide the to-be business process flows throughout the Sprint sessions that
the Sprint topics to illustrate the business process and expected behaviors of the AR capabilities.

This topic will be covered in a future session in Sprint 2. We have documented your question and we will cover this material du
that future session in January.

Agreed. This is not applicable for any bureaus at DOC. This will be reflected in our configurations accordingly.

We have provided the list of line and transaction types that are applicable and serve as our recommendation for DOC in the Bi
PowerPoint from our CS session in Sprint 1.
Our Billing session from Sprint 1 was used to provide all of the DOC-relevant examples as it relates to revenue recognition.
Yes, at a high level, they are similar; however, we can revisit the Oracle EBS definition. Please reference the materials from the
Deep Dive (11/5/2020): Line Types are used in the system because AR AutoAccounting gives the ability to define rules for deri
the accounting code structure. These line types may be used by different transactions like invoices, debit memos, credit memo
adjustments etc.​Each segment value of the accounting string can be derived from several sources such as Transaction Types,
Items, Customer Bill to Site, Salesreps, or Constant. ​
The AR subledger accounting method and derivation rules will be covered in Sprint 2.

We will circle back on this. This is an outcome of Sprint 1 that we are currently working on, and we plan to bring back up in a f
discussion.

We discussed this in our Reimbursable Agreements meeting in Sprint 1. Based on the outcome of that meeting, our internal te
has determined that we need further discussions with OS because of their extensive WIP process. Once we understand their
business need, we will be addressing this part of the solution with the other bureaus. We had a follow up session with OS on
11/30/2020. With the BAS PMO team, we are confirming next steps with the appropriate parties to review the WIP.

This topic will be covered in a future session in Sprint 2. We have documented your question and we will cover this material d
that future session on 2/4/2020.

Fundamentally, the AP and AR modules are distinct modules and different workstreams (Order to Cash - AR; Procure to Pay - A
The transactions within those workstreams have a natural linkage and drill down capability. For example, the for OTC AR Invoi
Receipt > Collection; for PTP, Requisition > PO > AP Invoice > Payment. At the most simple level, those two scenarios would no
overlap. However, there are scenarios where there could be AP / AR support a unique business process:

1) If a customer has paid an amount for which no more invoices are going to come and there is a need for refunding the custo
money, then there is an AR to AP refunds process which can handle this (this is called AP/AR netting - this will be discussed du
Sprint 2 on 1/22/2020).

2) The projects module will support activity related to reimbursable scenarios where there could be both AP and AR transactio
the AP expenditures are related to reimbursable agreement related projects, the Projects module receives the data from AP
modules. Also, the Projects module functionality has revenue and AR invoice data related to these reimbursable agreement re
projects. From AR, one can drill into projects (only for reimbursable agreement projects) and from project expenditures it is po
to drill into AP invoices. However, there is not a logical relationship between stand alone AP and AR activity directly.

This topic will be covered in a future session in Sprint 2. We have documented your question and we will cover this material d
that future session on 1/25/2020.
This topic will be covered in a future session in Sprint 2. We have documented your question and we will cover this material du
that future session on 1/22/2020.

Correct, electronic invoice submission is slated for Sprint 3 during the Vendor Portal sessions.
Yes, data validation will occur within the EBS system. Sprint 1 discussed the to-be AP Invoice validation business process that.
It is our understanding that PM003 provides point in time approval validation. If any error occurs, the system stops the transa
and returns the error to the end user. In the to-be business process, the user will create the invoice and match it to the PO. Th
business process requires the user to validate the invoice before invoice approval routing. The invoice validation will generate
error messages or holds based on the data input into the system.

Entry of invoice data is only manual for certain fields (i.e. Invoice number, invoice date, and invoice amount) based on specific
scenarios. The to-be roles and responsibilities will be discussed in Sprint 2. As part of the to-be procedures, there could be inte
data for the AP Invoices which would not require any manual entry.
It is a standard functionality in Oracle EBS to validate inputs on a per-field basis. There are built in validation rules that issue
messages/warnings when the rules are violated, such as missing required fields, or incorrect date or number formats. For AP i
validation, the system will check financial details such as matched amounts, distribution variances. The AP Invoice holds were
originally introduced during Sprint 1. The AP Invoice holds will be reviewed again on 12/14/2020 as part of the Configuration
Validation Session (CVS).

The invoice types included in EBS are:

Standard invoice
Credit Memo
Debit Memo
Mixed Invoice
Recurring Invoice
Expense Invoice
Withholding tax
Pre-Payment Invoice
Interest Invoice

Receipts will be entered as required for the appropriate purchase orders.

For a No-Match invoice, the invoice #, invoice date, and invoice amount are entered into the Invoice workbench. For this invo
accounting entry will be created so that the accounting string is associated with the invoice, which will also initiate the funds c
When the funds check is approved, the invoice will go through validation and approval for payment submission. If the funds c
rejected, the accounting will need to be reviewed, corrected, and then resubmitted for funds check.

Oracle Payments will be discussed during Sprint 2. In terms of the access to see different obligation data, the roles and
responsibilities will review the access (inquiry only, data entry, etc.). An inquiry role, view only, would allow users to review
purchasing data related to the obligation.

Create Accounting is a standard Oracle process that creates the corresponding accounting entries based on the transaction
accounting events. Based on the accounting conditions, the subledger accounting method will derive the accounting string (de
credit pairs) based on the defined posting model. During the invoice creation process, the create accounting step will generate
accounting string to support the invoice activity.

Oracle Payments and Travel interface will be discussed during Sprint 2.

The corrections button is not currently part of our recommendation for the standard invoicing process. This functionality is re
to credit memos where the system drives the correct credit memo amount via clicking on the button.

Integration will be covered later on in Sprint 3.

Oracle Payments will be discussed during Sprint 2.

Oracle Payments will be discussed during Sprint 2.

The IPAC discussion will take place in Sprint 3.

Correct, the process flow is a high level view. This will be walked through (on the EBS side) during the CVS for AP Invoicing on
(Please see highlighted question). After the Common Solution, the detailed business process would be documented which wou
support the eventual user acceptance testing. This process flow would also include the hand off between different roles includ
AP invoice entry vs. approvers.

To comply with the prompt pay act, Oracle EBS provides the following capabilities:
Due Date Calculation, Economically Beneficial Discount, Reason Code processes.
Oracle Payables module calculates valid interest penalties on late payments automatically from funds budgeted and allocated
program for which the late payment occurred.

Oracle Payments will be discussed during Sprint 2.

Yes, we can define a supplier as federally reportable by enabling the Federal in the Supplier setup.

Using the Due Date Calculation, Economically Beneficial Discount, Reason Code processes.

Oracle will support workflow related to the defined roles. AP Invoice Approval roles were discussed during Sprint 1 AP Invoice
discussion. There was a data call to bureaus to understand required approval levels. We are reviewing current DOC business
processes, and will provide a recommendation in Sprint 2.
Based on the business rules, we recommend that the approval levels be limited to 3. For example, the supervisor of the individ
who entered the invoice, the COR, the buyer. Based on the provided approval levels, we will highlight the way that Oracle pro
controls for AP Invoice entry that will simplify and standardize the AP invoice process.
Do you mean for obligation (PO) or invoice? There is no approval process for receipt entry. For contract awards, the PRISM
discussions will review this in Sprint 2. For AP Invoice entry, this is currently being worked as an item from Sprint 1 discussions
There will be a standard approval workflow for AP Invoice entry.

It is our understanding that CD435 is a Procurement Request which is the first step in the procurement process for purchases
purchase order, delivery order, and contract. These documents are prepared on the basis of the Form CD-435. Finance payme
made based upon the procurement document. In order for an accountable piece of property to match a payment record, the
CD-435 must be prepared according to the provisions of this Order. If this is the case, then the requisition would be created in
with the corresponding contract award also created from the PRISM requisition.

The IPAC discussion will take place in Sprint 3.

EBS will inherit the attributes and structure from PRISM for the UOM (whether that is quantity based vs. USD based). There wi
be rounding issues based on the business process in how the user should match. This will be explained as part of the to-be pro
during UAT and training.

Prompt Pay will be calculated based on the invoice date. After the invoice is approved, the Due Date calculation can be initiat
before the invoice is submitted for payment. The calculation compares the terms date with the goods/services received date.
Yes, there are descriptions for every line of accounting. in Oracle EBS.

Please confirm the business scenario where you would have one invoice with multiple POs referenced. Does DOC receive an in
from one vendor with multiple POs?

The recommendation for tolerances will be shared during Sprint 2.

The recommendation for receipts will be discussed in Sprint 3. Roles and responsibilities will be reviewed during Sprint 2.
The recommendation for tolerances will be shared during Sprint 2.
The Payables module has the standard functionality of creating invoices to pay off interest for overdue invoices.

Payables automatically schedules payment for each invoice based on the Payment Terms and Terms Date you enter for the in
Payables uses the Payment Terms definition to calculate the due date, discount date, and discount amount for each scheduled
payment. For example, if an invoice has Payment Terms of Net 30, Payables calculates the due date as 30 days after the Terms
You can assign default Payment Terms to a supplier.

Travel interfaces will be covered during Sprint 3.

We will walk through the details during the AP Invoicing Configuration Validation Session on 12/14.

Depending on the status of the AP Invoice, there will be defined business processes for the adjustment entries. Oracle suppor
capability where users can make adjustments to invoice details, distributions, and scheduled payments, even if the invoice has
posted to your general ledger or paid. The system allows you to reverse matched distributions and/or create new distributions
matching to new purchase order shipments or distributions of the same purchase order. If you add or reverse invoice distributi
you must also change the scheduled payment amounts to match the new invoice total, or Payables will place holds on the invo
during Approval. There will be a downstream process should you only need to adjust the AP Invoice information if the Paymen
details do not change (clearing invoice). You can use a clearing payment method to account for changes in the accounting
information / adjustment if you do not actually require funds disbursement. This is to be discussed during the session on 1/11
Sprint 2.

Oracle EBS system offers standard budgetary controls across the procure to pay life cycle and business flows - from commitme
through obligations and receipts, invoices(deobligations) and payments and the treasury confirmation. Obligations will origina
the acquisition system, PRISM. The deobligation activity will originate in PRISM and will pass financial edits before it is interfac
Oracle (financial system of record). It will confirm different financial edits (confirming the amount billed, etc.) before the deob
is processed.
Each responsibility will have identified reports that can be run ad hoc directly from the system. As part of Common Solution, th
standard reports process and recommended reports will be highlighted. The EDW workstream will review the data warehouse
mart strategy. Accounts Payable features such reports as:
- Use the Suppliers Report to review detailed information you entered for a supplier in the Suppliers and Supplier Sites window
This report also shows if a supplier is on PO Hold.
- Submit the 1099 Payments Report to create a listing of payments made to 1099 suppliers. Submit the 1099 Payments Repor
each tax reporting entity in your organization.
- Use the 1099 Supplier Exceptions Report to review 1099 suppliers with inaccurate or outdated 1099 income tax information
1099 supplier is a supplier that you have defined as Federally Reportable in the Suppliers window. You should run the 1099 Su
Exceptions Report before you submit your 1099 reports to identify suppliers that Payables will treat as exceptions in your 1099
reports. You can correct these supplier exceptions in the Suppliers window. You should submit the 1099 Supplier Exceptions R
for each of your tax reporting entities.
- Use the Invoice Aging Report to analyze the cash flow of your unpaid invoices. This report provides information about invoic
payments due within four time periods you specify in the Aging Periods window.
- Use the Invoice on Hold Report to review detailed information about invoices on hold. You can submit the Approval process
submitting this report to obtain the most up-to-date hold information. To obtain additional detail for invoices on matching hol
can submit the Matching Hold Detail Report.
- Use the Invoice Register to review detailed information about invoices including only those that are cancelled or not approve
-Use the Invoice Approval Report to review the total number of matching and variance holds that Payables applies and releas
you submit Approval. If you use budgetary control, Payables also lists any funds control holds.
- Use the Accounts Payable Trial Balance Report to verify that total accounts payable liabilities in Payables equal those in the
ledger. Before closing a period, you can compare the cumulative total liability provided by this report with the total liability pr
by your general ledger to reconcile these balances.

All invoices (regardless of the matching) will require system validation against the obligation for accuracy before going through
approval.
The person entering the invoice will be responsible for validating the invoice. After validation, the invoice is then routed for
approval. The person who entered the invoice is not the person (or persons) who will approve the invoice. The system has
automated workflow that will notify those required approval personnel via email as well as a notification that will be in their w
(this notification will be viewable directly as they login).

Based on the Oracle configured workflow rules, the system will automatically inform the next person in the approval queue of
required action. The workflow will generate the required notifications both to the individual's work list as well as their email
(associated to their user account). The queue of approval requirements can be seen at the document level (either through the
forms or drilled down in the notification). Both views will show who the document is currently assigned to for approval and th
status, approval date. This feature was reviewed during Sprint 1 and will be highlighted again on 12/14/2020. Oracle Payment
be discussed during Sprint 2.

We are currently preparing the recommendation for the approval hierarchy, but yes, we are looking at 2-3 tiers for approval. T
roles identified (buyer, COR, etc.) are part of the assessment.
The validation process was reviewed as part of the AP Deep Dive. The 12/14/2020 session will review this again as part of the
related to the validation process. The Validation process is required before submitting for approval. The validation and approv
process for AP Invoices will be handled on the Oracle EBS side. The recommendation for approvals is anticipated for Sprint 2.
process will be an automated one.

Seeded holds are just the out-of-the-box reason codes to place a hold on an invoice. No configurations are required to utilize
invoice hold reason codes. The invoice hold reasons were introduced during November 2020 and will be revisited in the 12/14
session.
Oracle Payments will be discussed during Sprint 2.
The standard business process requires that any new funding action be processed via a requisition to add that funding to a con
award. If the scenarios is that an invoice / payment is processed (which would have decreased the unbilled balance) and that
payment needs to be reversed, the invoice cancelled, etc. Oracle will support the resulting action if that downstream activity i
reversed. If the AP invoice matching is reversed, cancelled, then the system automatically makes that funding available on the
obligation and can be billed later.

Standard OOTB capabilities for reporting and trial balance information will be real time. The transfer process (from subledger
will be on a set schedule by the O&M processes. There is also a feature where the user can push to the GL as well directly. The
standard reports are real time.

Accounting can be scheduled to run periodically as necessary to transfer and post documents to GL. This will be part of the O&
SOPs and defined batch programs.

Validated and approved invoices are processed through a payment process request, which is a standard disbursement proces
Oracle EBS. Sprint 2 will provide the detailed review of the disbursement process. We will discuss the process after the AP Invo
entered and how the payment will be processed and resulting accounting entries for disbursement and Treasury confirmation

There is no time limit for invoices to stay in the system. The recommendation for the document attachments will be to only att
the supporting AP Invoice to the record. EBS is not intended to be the file repository system. The file limitation is a non-functio
requirement that will be established as part of the technical architecture team. There will be a size limit established for EBS. T
be answered as part of their Common Solution review.

Documents will not be removed by any system SOP. If documents need to be flagged for "legislative hold" - this can be configu
an attribute for the AP invoice. Documents can be flagged for "legislative holds" by using the descriptive flex fields in the Orac
system. Please bring up legislative holds during the 12/14/2020 discussion so we can assess the business impact if this needs t
be a configured hold as part of the validation process.
We need to understand the requirements for the documents storage capacity per invoice. EBS is not meant to act as a
documentation repository for the bureaus. It should not replace a share point or shared drive as it is not a file share system.

There is no requirement for invoice attachments.

There is a standard Invoice Tolerances table where we will define tolerances DOC needs to allow for variances between invoic
purchase order, receipt, etc. We can define both percentage-based and amount-based tolerances.
We are having internal discussions to determine the flow for partial payments. The recommendation will be discussed during
2/3.
This feature is called Data Access sets. The PTR workstream has featured the data access controls as part of their Sprint 1 sess
On 12/10/2020, the data access controls will be reviewed. The Data Access controls support data restriction so that a bureau c
only see their own data, but not others.
Sprint 2 will feature the discussions related to integrated data.

Bank account information is setup and maintained per supplier pay site in Oracle EBS. It will be based on the supplier and sup
site selected during the invoice creation. The supplier site can have specific banking information assigned to that vendor supp
site.

Yes, Oracle EBS supports the capability of multiple lines of accounting.

Oracle Payments will be discussed during Sprint 2.

Much of MARS functionality will be available in BAS (through Core Application and/or EDW Community Powered BI Marts).
Currently, the following MARS functionality will not be supported by the BAS EDW:
- Data entry to create/update operational or reference data - e.g. Table of Org. That type of activity needs to happen in the
operational system upstream of EDW.
- Data entry to annotate report line items - e.g. Variance explanations. Tableau has the ability to add comments to reports ove
but not to individual line items.
- Ingestion and integration of data from MARS specific data sources - e.g. NOAA RADS (Recruiting and Analysis Data System), N
Staff Directory, and FAAPS (Forecasting Advanced Acquisition Planning System).
- LO/FMC specific functionality that does not align with the BAS Program objectives - e.g. NWS (National Weather Service) Dire
Tracking

There are two parts to data standardization:

- Single instance and configuration of Core Applications where interfaces and fundamental data elements originating from tho
applications are standardized - e.g. Financial ACS structure. Those discussions are happening in Core Application Common Sol
workshops. That standardized data will be passed on to EDW.
- Potential cross walks required for data not coming from or interfacing with Core Applications - These will be determined as w
progress with development of the data model and ETL design for each EDW data source. During Requirements Grooming and
of Community Powered BI Marts, data integrations will be validated with Community Stewards, SMEs, and key Power Users.

Requirements Grooming for Community Powered BI Marts will entail getting information on common reports/data calls, inclu
data sources, queries, and sample reports. EDW will use this to validate required data is being ingested from data sources and
integrated in the EDW data model. In some cases data gaps may be identified for capture in a Core Application. Validation by
Community Stewards/SMEs/key Power Users and getting feedback will occur during respective Demo sessions.

There are a number of standard reports that come out-of-the-box (OOTB) with Core Application COTS software. Core Applicati
teams will present the recommended reports during Common Solution sessions and confirm with the Decision Making Forum
these meet operational reporting needs.

During Requirements Grooming, key data needs from across functional areas (e.g., HR, Finance, etc.) to support reporting and
analytics will be identified for inclusion in the Community Powered BI Marts.
Conversion data (e.g., data from CBS, C. Suite, FRPM, and Legacy Sunflower identified to be converted into the BAS Core
Applications) will be mapped to the BAS Core Applications data model and data structure, which will then be ingested and inte
into the BAS EDW. Legacy data (e.g., historical data from CBS, C. Suite, FRPM, and Legacy Sunflower that is not being converte
the BAS Core Applications) will be copied into the BAS EDW in its current data model and data structure. We will be following
practices; scope priorities and plan will be re-assessed at the start of every release and adjusted if needed so the highest value
features are implemented in the BAS EDW in the initial releases.

It is anticipated that bureau DWs will need to be available for a period after BAS deployment (e.g., to support year end
close/reporting activities). In addition, DWs will need to be available after BAS deployment to support the copy of legacy histo
data into the BAS EDW. Decommissioning discussions will occur closer to the deployment phase for each bureau.

Currently, Requirements Grooming for Position Planning will occur in FY23 Q3 with HR and Budget Community Stewards/SME
Power Users. Requirements Grooming will result in feature user story and acceptance criteria (requirements). During Dev & D
the BAS EDW team will develop the feature and demo to Community Stewards/SMEs/key Power Users to get feedback.

In Q2 FY2021, the BAS EDW Team will be working to establish a direct connection between NFC and the BAS EDW to ingest an
integrate additional HR and Payroll data to support managerial reporting and analysis (e.g., data needed over an above what
currently exists in the NFC labor and employee files).

In FY21 Q3, the NFC-EBS labor and employee interface will be discussed during the Core Applications Common Solutions sessio

Yes, a process will be established to update joins, add objects and data elements, etc. to the BAS EDW as part of the to-be defi
operations and maintenance processes.

During Requirements Grooming for the Budget BI Mart, data requirements and reporting needs will be identified to support b
planning and execution activities.

Yes, Community Powered BI marts will have access to data across business areas (see slide 11 of Global Design Outcomes: Bud
Finance Community presentation to see anticipated cross-business datasets for each Community). During Requirements Groo
common reports/data calls, supporting queries, and sample reports will be collected from Community Stewards/SMEs/key Po
Users to identify data elements for inclusion in Community Powered BI marts to support cross-area reporting (e.g., join of
acquisitions and finance data).

Data from Bureau specific interfaces to the BAS Financial application (EBS) will be included in the BAS EDW through the EBS-BA
EDW integrations. Slide 4 includes the applications for which a direct connection to the BAS EDW will be established (note: in
case on CBS/DW, C. Suite, FRPM, Legacy SF the direct connection is a one time connection to support the copy of legacy data i
the BASE EDW).

SAM will not have a direct connection to the BAS EDW. SAM will interface with the BAS Core Applications; vendor data will be
included in the BAS EDW via BAS Core Application integration.
Outbound data services may be provided to support bureau specific applications that require BAS data post implementation.
need and format (e.g. web service or data extract) for the outbound data service will be assessed during each Phase of the BA
implementation.

There are a number of standard reports that come out-of-the-box (OOTB) with Core Application COTS software. Core Applicati
teams will present the recommended reports during Common Solution sessions and confirm with the Decision Making Forum
these meet operational reporting needs.
AIM is Census' Acquisition Information Management System.

Copying over legacy data means copying of transactional data (and any relevant maintenance tables) from the legacy systems
BAS EDW will not copy documents (e.g., PDF files) that exist in some of the legacy BAS applications. The BAS EDW will include:
- Conversion data (e.g., data from CBS, C. Suite, FRPM, and Legacy Sunflower identified to be converted into the BAS Core
Applications) that will be mapped to the BAS Core Applications data model and data structure, which will then be ingested and
integrated into the BAS EDW.
- Legacy data (e.g., historical data from CBS, C. Suite, FRPM, and Legacy Sunflower that is not being converted into the BAS Co
Applications) will be copied into the BAS EDW in its current data model and data structure.

Yes, Community Powered BI marts will have access to data across business areas (see slide 11 of Global Design Outcomes: HR
Community presentation to see anticipated cross-business datasets for each Community). The Budget Community is slated to
access across all the administrative areas (e.g., acquisitions, HR, etc.).

Currently, Requirements Grooming for Budget/Spend Planning will occur in FY22 Q4, and for Position Planning in FY23 Q3. Du
these sessions we will be working with bureau staff to understand current tracking and reporting processes to help craft user s
for these features.

Community Stewards, SMEs, and key Power Users will be asked to participate in Requirements Grooming, Sprint Demo, and P
activities. These sessions will be smaller in size in order to effectively manage the requirements and validation processes and
conducted with bureau identified points of contact with representation across the Department (request forthcoming). Existin
communications channels (e.g., Table Talks, Town Halls, etc.) will be leveraged to update the broader BAS stakeholder commu
the status of BAS EDW activities.

Outbound data services may be provided to support bureau specific applications that require BAS data post implementation.
need for the outbound data service will be assessed during each Phase of the BAS implementation.

NFC and WebTV are the two HR related applications from which data will be ingested and integrated into the BAS EDW.

Enterprise Services (ES) participated in all EDW HR Global Design workshops. The BAS EDW will include HR and Payroll data fr
National Finance Center (NFC), which is the system of record. The BAS EDW team will continue to coordinate with ES on the
feasibility of ingesting and integrating HR Connect data into the BAS EDW (currently HR Connect does not have the capability t
provide a data service or data extract to the BAS EDW).

There are two parts to linking data:

- Transactions will be linked in EBS, which will be passed onto EDW.
- If applicable cross walks will be developed data not coming from or interfacing with Core Applications. These will be determi
we progress with development of the data model and ETL design for each EDW data source. During Requirements Grooming
Demo of Community Powered BI Marts, data integrations will be validated with Community Stewards, SMEs, and key Power U

A single enterprise data warehouse instance with a standard data model and data definitions used across the enterprise; this w
achieved at the end of the BAS implementation once all applicable DOC bureaus are on BAS.
The first ATO evaluation for the EDW application will occur Q4 FY2021, and annually thereafter. ISAs govern the authorization
additional data streams. If new data is approved through an ISA, it does not require waiting until the next ATO to be enabled
the new data impacts the privacy posture of the application.

The data sources shown in the EDW Global Design Outcomes presentation are the data sources that feed directly into EDW. T
are other systems that will interface with Core Applications. Data captured in those interfaces will be fed to EDW.

Data from applications that will interface directly to a BAS Core Application (e.g., USCG-EBS for NOAA Corps Payroll), will be pr
through the BAS Core Application-EBS integration. During Requirements Grooming we will be determining data requirements
support reporting that may need to be captured in the BAS Core Applications (e.g., GOAL Codes).

BAS Core Application interface requirements is driven by new/updated business processes being discussed throughout commo
solution.
During BAS EDW ETL design for each of the core applications, the team will be assessing all data captured in core applications,
addition to interface data.
BAS EDW will use common reports/data calls, and supporting information (e.g. data requirements), captured during BI Mart
Requirements Grooming to validate against ETL designs.

During Community Powered BI Mart Demo sessions.

During Requirements Grooming for the Community Powered BI Marts, data needs from the applicable data sources/areas will
identified. For example, when building the Finance BI Mart, the BAS EDW Team will work with Community Stewards, SMEs, an
Power Users to identify data needs from cross business areas (e.g., HR, Travel, etc.) to support managerial reporting and analy
along with data call responses.

Power Users will have the ability to upload data to Tableau to enhance reporting datasets. During Requirements Grooming se
for the Community Powered BI Marts, data and reporting needs will be identified (including data sources).

The objective of the BAS EDW is to provide the Department, Bureaus, Line/Lab/Program offices the tools and capabilities need
manage their business, anchored on operating consistently as an enterprise. This will be achieved by providing a single standa
instance of an enterprise data warehouse -one-stop-shop for data needs –for use across the Department, Bureaus,
Line/Lab/Program Offices as common ground for data and insights, along with providing a robust reporting tool to empower u
build reports and dashboards to support managerial reporting and analysis. As we progress through the EDW implementation
Bi-weekly BAS Program Update meeting can be used to confirm the BAS EDW is aligning to its goals.
For BAS, Tableau will be used to support both BI reporting and data visualization/analytics capabilities. While Tableau is know
its data visualization capabilities, it does have the ability to support more traditional report development similar to what burea
used to in Business Objects. For example, the Community Powered BI Mart power users will be able to drag and drop data ele
to create report rows and columns and will have the ability to include aggregations, etc. To enable a "drag & drop" style of ad
reporting, pre-joined datasets that will be published as a data source (similar to what the abstracted data semantic layer in oth
reporting tools provide). Alternatively, Tableau also provides the ability to create reports by connecting to tables directly and
creating the relationships.

BAS Core Applications will introduce standard reporting that users can leverage for real-time information directly from that sy
Depending on the requirements, there will be EDW reporting capabilities as well that enable the user community to create rep
from the available data elements that will be refreshed as part of a daily schedule (the data would reflect the prior day’s
information). Each Core App workstream will be providing more details on standard Reporting and Capabilities features startin
Sprint 2 and Sprint 3.

The transaction in EBS are derived from the Subledger Accounting (SLA). Each Transaction in EBS are classified by events and,
each events, the accounting rules create the appropriate debit and credit entries based on the Subledger Accounting rules. Ex
of events are invoice creation in Payables, Credit Memo in Payables...etc.

The SLA is configured by subledger application (Payables, Projects, Receivables, Purchasing.). Each subledger will maintain tho
corresponding accounting entries for the transaction; a user can review the accounting transactions at the individual transacti
level.

There are detailed discussions to review all parts of the ACS segment. BAS CS Sprint 2 will review each segment individually in
upcoming sessions (Please refer to the CS Calendar for those sessions scheduled on 1/25, 2/16). Org is part of ACS Review Sess
and this should provide clarification on how Org values will be structured in BAS. We will also review the Project / Task numbe
and how this module will support the tracking and reporting of expenses and revenues. The Projects and Tasks discussions wil
in Sprint 2 (March 2021).

We are currently gathering additional information on these types of obligations and are planning to set up a meeting to discus
scenarios further with NIST. The PRISM award sessions, which will cover award obligations from PRISM to EBS, are scheduled f
Sprint 2.

There will be an interface to synch up vendor data between SAM and EBS/PRISM. The to-be process for vendor maintenance a
of the O&M model is still under review with the BAS PMO.

EDW Community Powered BI Marts will include data from the BAS EDW, which receives its data from the BAS applications. Da
not be real-time data (i.e. application data).

The e-invoicing requirement is currently being reviewed by the BAS team.  The recommendation will be discussed in thorough
Sprint 3. We will work with the BAS PMO to understand the business requirements related to the vendor volume.
You can take two approaches, one, use your best judgment and submit. The risk lead will review and contact you with suggest
changes. Alternatively, please contact the Risk Lead to further discuss and obtain clarification.

Much of MARS functionality will be available in BAS (through combination of Core Applications and EDW Community Powered
Marts).   Workforce data is planned for inclusion in the BAS EDW.  The BAS EDW team has been working with bureau HR SMES
including the NOAA Office of Human Capital Services, to understand the NFC/workforce data that is currently used in reportin
such as MARS.  This information will be used in future discussions with NFC regarding how the BAS EDW can pull/receive the s
information. 

We are planning to start Real Property User Acceptance Testing (UAT) in early-April.

Today, the quantity-based and dollar-based item solutions are available between PRISM and EBS. The quantity vs. dollar will b
established on the requisition and inherited as part of the contract award. The AP Invoice will match to that PO based on quan
dollar, etc. We will be discussing payments in our upcoming Sprint 2 sessions.

The BAS Core Apps team is currently working with BAS PMO team to create new structure for the BAS ACS segments and build
crosswalks for these segments to show current CBS ACCS structure to new BAS ACS structure. In CS Sprint 2, there will be multi
sessions with bureau DMF groups to review the new structure of BAS ACS segments and share the crosswalk workbooks for th
input.

PRISM (BAS Acquisitions Management application) has standard reports that contain real-time acquisition data.  PRISM also h
Analytics reporting capabilities that report on real-time acquisition data. 

(1) Yes – the BAS Core Apps team is working with our BAS PMO team as well as the CBS Team to understand the required
collaboration for the future G-Invoicing support. the BAS Core Apps team also have routine discussions with the Unison PRISM
Oracle EBS G-Invoicing teams to understand the future capabilities to support the G-Invoicing mandate.

(2) G-Invoicing is part of the BAS Go-Live solution for day 1.

(3) The integration points for the G-Invoicing capabilities will be available at a later point per our Common Solution schedule. T
attributes and supporting capabilities for G-Invoicing will be reviewed as part of the Sprint 2 – Sprint 4 discussions. Note that t
solution will fully support G-Invoicing integration.

Yes, Tableau training for BAS EDW Power Users and General Users will be provided. At a high level, Power Users will learn how
create reports and visualizations on behalf of their community (e.g., Travel, HR, Grants, Finance, etc.) and General Users will le
how to access and generate reports within their respective community (e.g., Travel, HR, Grants, Finance, etc.).

The BAS Data Lake and Enterprise Data Warehouse (EDW) will both exist in the same Amazon Web Service (AWS) FedRAMP
authorized GovCloud environment. Tableau can connect to and query multiple data sources (e.g. the Data Lake and EDW) in a
query. Specifically for joining legacy and new data, depending on the specific scenario and complexity of joins, some additiona
structures may need to be created by the BAS EDW team to support joining legacy data to BAS EDW data structures and simpl
Tableau queries. These needs should be identified during requirements grooming for BI Marts (i.e. data requirements to supp
common data calls/reports).

We have reviewed this with the BAS PMO. We will review the requirement related to the work number tracking. In NIST’s
implementation year, we will look into this process and identify the appropriate solutions. For now, BAS has logged this conce
the Internal Tracker as a flag for the appropriate parties [SF (assets), PRISM (acquisitions) and Oracle (Projects)].
Sunflower Real Property includes both read-only and “edit” roles. Users with “edit” access will be able to edit/update informa
the system without going through BAS PMO or the Operations and Maintenance (O&M) team.
Yes, users with “edit” access will be able to update several leases at a time by using Sunflower’s Data Migration Toolkit.

We do not currently plan to have annual or semi-annual shutdowns but can re-evaluate that approach if a requirement arises.

The Real Property deployment will be within the current Sunflower instance, on the DOC/Bureau network, and will leverage u
Windows login for SSO.

Yes, the Acquire to Dispose team has discussed this topic, and we expect to discuss it with Bureaus when we begin holding Pe
Property Common Solution discussions in Spring/Summer 2021.

During the EDW Community Powered BI Mart Requirements Grooming Sessions (scheduled throughout FY21), the BAS EDW T
will work with bureau subject matter experts to identify data elements that need to be available in the EDW to support reporti
The EDW Data Model and Catalog will include the list of available fields from which Community Powered BI Mart Power Users
use to build reports. The data model/catalog will be published on the BAS Portal and a process will be established to
communicate/publish upcoming changes to the data model/catalog (e.g. for addition of data sources such as GMIS and USPTO

BAS portal is internet-facing, but restricted to those who are within the DOC network. The DOC IP address range is whitelisted
users coming from the DOC network will have access to the BAS Portal homepage. Users will be required to provide authentic
credentials for SSO.
BAS teams are currently developing contingency Plans, Procedures and an overall Continuity of Operations Plan, but since BAS
utilizing multiple FedRAMP authorized CSPs, each SaaS providers has built in redundancy and recovery features that come inh
with virtual cloud environments.

The future BAS O&M model is still under review. This will be confirmed as part of the first Phased Deployment Year where the
different tiers and support model are defined. As far as help desk (HD) concepts, there will be defined roles that require differe
access (whether that is front-end or database access). The O&M intent will require that the HD have the appropriate tools and
access to triage and resolve any issues that are submitted. If that troubleshooting requires specific capabilities like creating an
query, then there would be the appropriate access granted in line with the security parameters for the overall BAS footprint.

Per DOC HVA Identification Guidance, we must obtain agreement from the System Owner (Teresa Coppolino) and approval fro
Bureau Chief Information Officer (Andre Mendes). The BAS co-Authorizing Officials, Stephen Kunze and Larry Anderson will b
to review the results of the HVA ID Tool as well.

Yes - we can send an update to the invitation with the slide deck attached.

Currently all Security Sessions are being held internally with the BAS PMO. There will be meetings in the future that will open u
Bureau representatives who will receive invitations.

Yes - all CS participants will be invited to Sprint closeout and kickoff meetings.

This information can be provided on request to the BAS Risk Lead, Rakesh Raman, at rraman@doc.gov

BAS Technical Architecture documents will be shared at the appropriate time and with the appropriate audience. It will not b
available to the general BAS user base due to the sensitive nature of the material.
This has been added to the BAS Website (https://www.commerce.gov/ofm/bas-homepage/business-applications-solution-b
the About Us section.

Beginning with January 2020, all Menti.com results will be included as an appendix to the slide deck posted on the website aft
meeting.
Each phased deployment year will take place over one fiscal year. For example, NOAA is scheduled for FY2022; NIST, FY2023; C
FY2024. During the phased deployment year, the bureau will continue to leverage their existing system (CBS or C. Suite, etc.) u
the deployment window which will take place during year open. For NIST, FY2023 NIST will have SDLC tasks to support the
deployment in September / October 2023 timeframe. NIST will continue to use CBS in Q1-Q4 until that cutover timeframe.

Given GSA’s current UEI transition timeline, BAS will go live with UEI and it will be added at both the system setup and docume
level.

The DUNS field will be available for legacy transactions.

BAS will support uploads to the General Ledger via a Journal Voucher (JV) which is similar to the CBS GJ capability. The Core Ap
team is reviewing the Journal Batch process as part of the Sprint 2 meetings. This requirement will be reviewed in context with
journal capability as well as the Year-End Close process requirements.

One of the goals of the EDW is to have a centralized reporting tool that any organization can use to meet their reporting need
the case of OFM, this may require access to data for Bureaus across Commerce. During the requirements grooming sessions f
Financial data in FY21 Q3, OFM will have an opportunity to provide the data elements that they require to do their reporting,
determine if they are best sourced within EBS or the EDW. Users (including OFM) will have the ability to generate their own a
reports via drag and drop capabilities out of EDW.

The CBS Budget Operating Plan (BOP) is a Commerce-specific business process. The BOP requirement was identified during rec
Sprint 2 discussions. As part of the Common Solution, the Core Apps team will work with the EDW team to assess the requirem
and supporting capabilities. Additional questions and follow up sessions could be required to confirm the business process. Th
EBS capabilities that mirror the BOP outcomes; the BAS team will work with the DMF to confirm the requirements and to-be B
solution.

The Phased Deployment year will include the testing activities (including UAT) and training plan for each bureau. Dedicated te
for NOAA will take place in FY2022Q3-Q4. UAT will include the guided test scripts with the supporting legacy data during that

Each phased deployment year will take place over one fiscal year. For example, NOAA is scheduled for FY2022; NIST, 2023; Ce
2024. Each of these years will require different software lifecycle activities for that user group that is going-live. You will conti
using your existing system; a double entry approach is not required. There will be a "cutover period" or data freeze when the
selected for conversion has been identified. There will need to be a collaborative discussion (with BAS PMO/bureaus) on a
decommission strategy for the systems.

Throughout FY21, the BAS EDW Team is working with functional and technical SMEs to gather data requirements to support E
report development by EDW Power Users. Currently, pre-built reports are not planned for development by the BAS EDW team
However, the current plan does include development of advanced analytics features. At the end of the Core Application Comm
Solution phase, analysis will be performed to determine if there are prebuilt reports that should be developed by the BAS EDW
particularly in cases where a report is intended to be used Department-wide.

Active Real Property records (assets, leases, projects, etc.) as they exist within Federal Real Property Management (FRPM) sys
will be migrated into BAS Sunflower Real Property on 4/23. After the transition to BAS Sunflower Real Property, all FRPM data
including historical data, will be archived for future access. The Real Property Operations & Maintenance (O&M) team will hav
access to provide data extractions from this archive, as needed. FRPM's historical data will also be available in EDW through t
BAS release in 2022.

Out of the box, the Oracle standard reports have an enabled flag as set by Oracle (where some are enabled; some are not). W
working with our PMO counterparts to determine the approach to review the report inventory as well as the reporting details
report parameters, output, etc.,). We will provide those details as to which reports are exportable into the specified format. T
effort is currently in progress with the supporting activities taking place until June 2021.
The BAS SaaS solution, including EBS and PRISM, are hosted by different hosting infrastructure providers. Due to this, BAS will
support a site-to-site VPN between the SaaS solutions in order to connect and provide a seamless BAS end user experience.

The current deployment plan involves deploying the Enterprise Service users that support NOAA, EDA and BIS for C. Suite toda
the initial NOAA deployment. If there are cross-servicing scenarios that involve NIST or Census C. Suite transactions that are
currently interfaced to NOAA CBS than those users would need to be deployed with the NOAA PRISM deployment or the
transactions will need to be manually entered. We will work with DOC to determine all the various cross-servicing scenarios a
determine the best course of action depending on the volume of transactions for each cross-servicing scenario. We would we
scenarios and transaction volumes associated with these scenarios from the bureaus to help in evaluating the best solution to
address cross-servicing. We have added this scenario to our outcomes tracker; as part of our overall conversion strategy (Spri
we will discuss with BAS PMO and provide follow up to the user community in future discussions.

We are looking to train the user population across all the applications (Oracle, PRISM, & Sunflower). We have not collected sp
names for people to be trained or names of specific people that will part of the User Acceptance Testing (UAT) as that part of
project phase is not scheduled until later in the Phased Deployment Year. Each Phased Deployment Year will focus on the targ
audience for that Deployment Year. That is, for Year 1, NOAA will be included as part of the UAT leveraging the converted data
part of that Phased Deployment Year 1 activities.

Yes. That will be part of the overall BAS ATO. Both PRISM and EBS in Accenture Federal Cloud Enterprise Resource Planning (A
currently have FedRAMP Authorizations. We will be leveraging both for the overall BAS ATO with DOC.

As a general rule, we try to avoid data fixes due to downstream impacts. It is not common that data fixes are needed, but if th
situation arises, we work with Oracle during the support process to address any operational item that needs remediation. BAS
collected these queries in an unofficial data call capacity. Feel free to send any information to us regarding any pain points or f
feedback.

We are within the first 18 months of collaboration on the single configuration. The first 6 months was global design; now, (FY2
we are in the Common Solution Phase. Right now, the core configuration of your system is being determined. There are variou
workshops across all of the workstreams. We encourage you to please continue to help us collaborate on the single configurati
Additionally, Real Property goes live at the end of April, and we have Census users that will be play a role in this.

During Sprint 1 and 2, the Core Apps team has reviewed the Oracle standard business process for customer data maintenance
are aware, there is not a federal interface for customer data to enforce standardization. We need to understand the process t
and provide the Oracle capabilities, which includes unique customer data. Business process flows will also need to be reviewe
ensure conformity.

Yes. If we need to have ad hoc Q&A sessions, we have the flexibility to schedule those throughout the spring/summer.

Our goal is to provide system walkthroughs as quickly as we can, but there are configuration settings and conversations that n
occur on the Common Solution side before we can build environments to show the system processes. The CS decisions are inp
into system build and configuration items to develop the to-be business processes. We are already showing system business p
flows as part of the Common Solution Configuration Validation Sessions in Month 3 of each Sprint.

During Requirements Grooming for the Acquisition, Budget, and Finance BI Marts, Bureau SMEs will identify acquisition and fi
data elements for inclusion in the BAS EDW. EDW Power Users will be able to write Tableau queries/build reports that join EB
PRISM data as identified during Requirements Grooming.
The functionality to write custom SQL within the Tableau desktop interface will be available to power users.

No, Power Users will not have access to databases (i.e., Toad/SQL to Core App’s databases). If BAS Applications such as EBS St
Reports (Operational and Real-time) or PRISM Reports do not meet DOC’s reporting needs, Core Apps would love to hear spec
business cases. For more information and guidance on this topic, you can reach out to Antion at antion.anderson@doc.gov an
for the slide on BAS Core Apps/EDW BI Mart Reporting Requirements.

The EDW will copy historical data from legacy Financial, Acquisition, and Property Management applications. It is anticipated
the data will be copied as of the inception of the system, subject to to-be defined requirements.

The capability to post content for each bureau and their customers will be available. We are still determining which DOC users
permitted to post content on the BAS portal. We would like to hear examples from bureaus to assist in defining this process.

Yes, the bankcard component (i.e., P-card/T-Card) and their transactions will be handled in EBS, integrated to the banking syst
SP3. The SP3 P-Card discussion will transpire in Sprint 3, which is slated for 6/8/21. We plan to discuss P-Card process, unique
scenarios for P-Card transactions, reconciliation processes, EBS interface data flows/etc.

We are capturing (and will continue to capture) lessons learned from the Real Property implementation to inform future
implementations. This includes identifying both the positive aspects that will be leveraged for future implementations, as well
those areas where changes will be made to address the unique features needed for specific bureau implementation. The infor
will be documented and provided to the BAS user community.

The BAS Technical Architecture will not be provided, but during the integration and design discussions, the Tech Arch team wi
Bureau specific touchpoint of the BAS architecture for validation of data transfer protocols ad timings.

Throughout the remainder of FY 2021, the BAS EDW and BAS Functional teams will be reviewing bureau responses to the Core
Application operational reports and EDW requirements grooming data calls to identify reporting scenarios that will be support
the EDW and/or a BAS Core Application. Reports identified as being supported by the EDW will be further analyzed to determi
whether the BAS EDW Team or to be identified bureau EDW Power Users will be responsible for report development. The res
this analysis will be used to determine the timeframe in which some EDW Power Users may be able to access the EDW environ
to build reports. Additional information is targeted to be provided in FY 2022 Q1.

https://www.commerce.gov/ofm/bas-homepage/tools-and-resources/bas-town-hall-presentations - Town Hall decks are atta

BAS Website would be a public dedicated website for all efforts related to the BAS Implementation. The CSC portal is where al
propriety documentation is stored regarding the BAS implementation.

The High-Level Program Schedule is posted on the BAS website, under the Tools & Resources section. It can be found here:
https://www.commerce.gov/ofm/bas-homepage/tools-and-resources/bas-schedule

We send a list of captured Q&A's after the Q&A session and not prior. Additionally, the Q&A's are on the website. This URL con
all Q&A's that have been captured thus far, https://www.commerce.gov/ofm/bas-homepage/questions-about-bas
IUS will be on the list of topics for Personal Property and discussed in future sprints. The team will provide more information w
becomes available.

There was a Core Apps PTR data call out to the bureaus to provide detailed accounting information for the known SLT scenario
was recently completed in April 2021. That feedback is now under analysis to validate if there are any discrepancies / similariti
across the bureaus. From there, next steps will include: confirmation of accounting impact for SLTs to help develop the busine
process for SLTs which will include the SOP to support processing the SLT impacts in conjunction with the Oracle EBS subledge
accounting methodology. The solution design is in progress with Sprint 4 targeted for review of proof of concept.
We recognize two common problems that occur in communications: 1) communications don't reach the right people and 2)
communications are disseminated to too broad an audience. We want to address both of these situations. We are requesting
information regarding this question which indicated that the audience was too broad. If this is your question, please reach out
using the "Submit a BAS Question" option on the BAS website, or email us at BASproject@doc.gov. We will discuss the situatio
you to determine the best approach for resolution.

Elements of the implementation strategy/plan have been communicated through the various BAS program communication ev
(Town Hall presentations, Table Talk presentations, Global Design and Common Solution Kick Off Sessions/Workshops, Executi
Stakeholder presentations). Materials from those sessions are available on the BAS website and can be accessed if there are
questions about the implementation strategy.

The BAS EDW Team continues to work with NFC on the data transmission approach for ingesting and integration HR and work
data into the EDW. Updates on the status of these activities will be provided at the next quarterly BAS Program Status Update

Commitment accounting will be established as part of the BAS subledger accounting method. For all activity that needs to leve
the Treasury-defined USSGLs related to the commitment activity, we will leverage the accounting events to support that activ
will discuss more about the processes related for non-PRISM commitment activity. For integration specific conversations, we w
confirm the anticipated activities and resulting accounting. For the travel interface, funds are not typically committed – Travel
typically only includes obligation (authorization) and expenditures (vouchers).

Yes. They will be sent to the participants and incorporated into the larger Q&A document that is kept updated on the BAS web

Yes BAS Users can add content to the Portal, but not to the Oracle database table. What type of information are the bureaus l
to add to the portal?
Additional sessions related to commitment accounting for budget and planning business case scenarios will be featured during
4.

As far as the decision process, the overall Power User / Report Creator model will have more information shared on it in Q1 in
It is currently a work in progress. Additional information will be noted and documented in additional sessions with the team.

BAS Program Common Solutions sessions have been recorded. The url where they can be found is
https://www.commerce.gov/ofm/bas-homepage/tools-and-resources/bas-common-solution-kickoff

The data integration method will differ depending on the type of transaction and system. The current approach is for CWT/E2
Authorizations and Vouchers to be processed in near real time. All other integrations for CWT/E2 and SP3 (CBA files, SP3 mon
invoice/correction files and reference data for CWT/SP3) will be batch processing

The overall high level implementation timeline can be found here https://www.commerce.gov/ofm/bas-homepage/tools-and
resources/bas-schedule. We are looking at a few options for making it available through the BAS Website homepage as well.

(see response for # 378)

Currently direct database access for end-users is not planned for any BAS applications. In EDW, Power Users will have the abili
develop reports to query data for reporting needs.
Currently, the reporting capabilities for EBS will be the standard out of the box reports. We are assessing the capabilities as pa
recent Oracle patches related to other reporting options. More information will be provided as we work with the EDW team to
assess the to-be.

There will be a dedicated test phase and environment to validate all integrations as part of the Phased Deployment Year 1.

Yes, Tableau supports export to multiple formats including CSV, Excel, PowerPoint, PDF, and Image.

Yes. If you search this file for Q&As that reference “ad hoc” you will see both general and more specific information about the
of ad hoc reporting that have been identified. Additional information about ad hoc reporting is available on the “EDW Fact She
which is located on the CSC Portal.

We occasionally have been asked for this - and recognize that for some, seeing the response in written format is desired. Beca
some of the answers are very extensive, they will not fit on the slide. We also typically get just as many questions pre-session
receive during the session. We do send all Q&A's to participants following the session. Pre-submitted questions are typically a
within 30 days to the individuals that pre-submit a question.

Commitment accounting will occur in BAS Core Applications. As previously discussed, both PRISM and EBS supports commitme
accounting. There will be additional sessions in June to discuss different business case scenarios of as-is commitment reportin
how those will be handled in BAS Core Applications. This will drive the related standard reports being assessed for PRISM, EBS
data requirements to support any additional report development required in the EDW.

EDW Power Users will have the ability to develop EDW report queries/SQL through the Tableau BI Reporting Tool. The EDW d
model and data catalog (listing of EDW tables and fields) will be published on the BAS Portal and will be accessible based on to
defined security and access controls.

We are starting to look at this at as part of the Labor Interface as part of Sprint 4 and what the accounting entries will be as fa
actuals vs accruals. Typically we would anticipate that labor would create the expenditures as part of integrated cost data into
projects modules (with the supporting 4902 entries). There is a larger ongoing conversation around commitment accounting (
planning / budgeting aspect of those planned costs). These conversations will occur in June / July.

Yes, Tableau supports dynamic prompts – e.g. automatically populate the latest time period; parameter values driven off of ot
parameter selections, pick from a list of values generated real-time.

Yes, Tableau supports recurring schedules for reports.

The configurations specific to manually entered Journal Entries/Approval were covered in the session. There are no additional
configurations remaining to be covered. Without specific information on the numerous other questions referenced we cannot
provide a response to that at this time.
Journal entries will be configured to post upon approval. While there is a brief time while the system processes the approved
entry this should not be confused with lags associated with typical batch processing.
Bulk approvals would be associated with Web ADI functionality that will be covered in Sprint 3.
We need more information to appropriately respond to this question, please resubmit with more information on the types of
you are referencing in this question.
You can post it manually regardless of having the categories defined to post automatically. Manual posting can be done anytim
after getting entries approved.
Generally speaking, it depends on the configuration in question. However, in the example provided, all three bureaus express
desire not to use the approval limit functionality. This configuration was tabled given the bureau's responses.
Yes, this configuration was shown and discussed during the CVS on 3/4, which was part of the CVS Checklist portion.

Revenue account can be edited at any point without an adjustment. For example, if you have a revenue line of $1000, the ACS
be edited and a new revenue account, object class or fund can be used in place of the old values. However, the $1000 revenue
cannot be split into 3 lines with different ACS strings. This rule is applicable when the transaction is already accounted and
transferred to GL. If no accounting is run, the lines can be edited and split into multiple lines. For changing the receivable line a
adjustment activity is needed.

The second level approval hierarchy is not required in Oracle EBS. This is something that is configured upon request. In terms o
approval limits and approval, this is a business process that needs to be discussed internally and our team will configure based
needs of DOC.

A list of adjustment reasons in EBS can be provided upon request.

This is a discussion topic for the RBAC meetings. In terms of level of responsibility, the user will need an elevated responsibility
make changes (i.e., SYSADMIN or Receivables Manager).

No, this needs to be set-up by user. Adjustment limits and adjustment approval hierarchies are not required in Oracle EBS.

This is a discussion topic for the RBAC meetings. In terms of Oracle functionality, the bureau will need a designated user with
elevated responsibility in the system (i.e., SYSADMIN or Receivables Manager) to do this.

We are having ongoing NOAA discussions on this business case during our cost allocation series. We have not gotten to the po
the series where we provide a walkthrough of this process just yet. Additionally, our team is finalizing the cost allocation upco
meeting schedule with BAS PMO.

We are planning to utilize Sprint 3 to discuss the Seafood Inspection process with NOAA.

An adjustment means you are reducing the receivable or increasing the receivable or correcting the acs. For loans, you can ap
adjustment to a loan, principal, interest, penalty or anything.

Yes, the Oracle AR module will handle DOC's need. We have provided a walkthrough of how to attach revenue accounts to line
as well as invoices in Sprint 1. Every bill has to have a RA.
We are aware of NOAA's need to handle GSA and overhead waivers. This question is more closely tied to the conversations we
currently having with DOC on Cost Allocation and Burdening. We are only in Phase 1 of these discussions and we have dedicat
sessions in Sprint 3 on this topic.

Yes, Oracle's adjustments functionality covers this process, which we discussed during the CVS on 3/4.
Yes, there will be five adjustment types: Invoice, Line, Freight, Tax, and Charges, which we discussed during the CVS on 3/4. Al
these are applicable to the DOC One Solution except tax. We plan to have further discussions with NIST to understand their ne
capture freight (this is not something the other bureaus have a need for). Credit and debit memos have already been captured
adjustment reasons.

Yes, there will be a list of eligible items to add in bulk. 100+ can be added at once. It’s a two step process. Run a report based o
criteria for the batch; this returns a list of items based on the query; one or more of the items returned can have an adjustmen
generated; if the user that created the adjustments has the proper limit the adjustments can then be approved. Credit memos
not be created in bulk. As it relates to having Oracle show the end user a list of adjustments, you can use the query feature we
showed the DMF during in the CVS on 3/4.

In Oracle projects, a user can track costs and billing against projects. Quick question on this, does the cost transfer happen bef
after the billing? This will help guide a more in-depth answer. This will dictate whether an adjustment / revenue write off nee
be processed or cost adjustments made in Oracle Projects.

These are specific to OU. There are no DOC level ones, unless we want to have them be common with the DOC. All transaction
come from an OU, so anything that comes from the DOC level will have to have a corresponding OU entry.

There are five main adjustment types. These are standard to Oracle and cannot be modified. However, you can change the
description of the type. For example, you will still have to select "Charges" even though the more widely known term at DOC i
"Dunning". With each Adjustment Type, there is another column that describes the type and with the right permissions, you c
modify the description.

Yes, this refers to all of the applicable types.

If it is project based, a user can adjust in the projects module and a user can move between projects. For example - someone h
charged the wrong project and task, it can be moved. Users can define any number of adjustment types as possible and users
make it as an invoice or line. If it is for finance charges, users will pick the type of charge and create that many adjustment acti
We will be having more discussions on the labor functionality in Oracle EBS and other interfaces that may be needed in Sprint

It is set at the user level by someone with elevated Oracle EBS responsibility (i.e., SYSADMIN or Receivables Manager). But the
will be restricted to the bureau. Even though there are limits, a NOAA user cannot set approval limits for CENSUS. BAS Core Ap
cannot comment on how approval limits will be set within each bureau as this relates to specific business processes that need
discussed further internally. Additionally, we provided a walkthrough of the Approval Limit screen.
The typical end user would not have the ability to edit these fields. The SYSADMIN team would grant specific users with this el
permission.
Yes, the typical end user would not have the ability to change/edit the reasons. This would be an elevated level of responsibili
system access (i.e., Receivables Manager or SYSADMIN). However, SYSADMIN is not necessarily required. There will be future
discussions dedicated to this.
Yes, users can do batch uploads of adjustments. There is an automatic approval adjustment process. Report board - based on
certain transaction type users run a report, it will list out items that match the criteria. It will show a list of items that are eligib
be adjusted. Second step - create. The adjustment can be created in bulk. This is one of the main differences between bulk
adjustment and credit memos. Credit memos cannot be created in bulk. Credit memos can be routed through the approval pr
users have to do approval management in user rules and have to define rules. Adjustment always has to go against specific
invoice/transactions. A credit memo can stand on its own, users go to the transaction workbench and can create.

1) Standard means NOAA receives the checks and sends them to the bank for clearance: i.e. checks cashed through Over -the-
Counter Channel (OTCnet). Then the bank clears the checks and a deposit ticket is created. No-Remittance: For example custo
pays through pay.gov or sends a check to the designated Treasury lockbox (U.S. Bank), and the payment is cleared either by pa
or the U.S. Bank. In this process NOAA does not have to send the receipts (i.e. checks) to the bank to clear.

2) It means check has been cashed and funds are remitted to NOAA 3-5
have dedicated sessions with the integration team on these topics starting in Sprint 3.

1) We will be providing an in-depth walkthrough of the screens during the CVS on 3/16.
2) We are planning to utilize Sprint 3 to discuss this topic. The calendar is currently being finalized and we do not have a solidifi
date.

Yes. We will discuss in further detail during the CVS on 3/16. During the session on 1/22, we did show the DMF how Oracle ha
this when there is no customer #. However, we recognize that this is a common need across the department and so, we will h
dedicated session on this in Sprint 3. The calendar is currently being finalized and we do not have a solidified date.

The cash can be matched to the bill during the receipt application process.

The AR009 screens in CBS is used for unbilled collections (no bill/receivable was created).

Every lockbox upload process gives a list of receipts processed successfully as well as those that failed validation process. We
planning to utilize Sprint 3 to discuss this further by walking through the lockbox process.
1) We will be providing an in-depth walkthrough of the screens during the CVS on 3/16.
2) We have a dedicated session on this topic in Sprint 3. The calendar is currently being finalized and we do not have a solidifie
date.

We plan to discuss this during the CVS on 3/16.

AR008 billed collection screen.

1) We will be providing an in-depth walkthrough of the screens during the CVS on 3/16.
2) We have a dedicated session on this topic in Sprint 3. The calendar is currently being finalized and we do not have a solidifie
date.

Yes a receipt can stay unapplied until research is complete and all the information is available.
AR001 receivable screen and querying using the customer name to find out if there are any open receivables with amount due

A screen shows what rules a lockbox uses in applying receipts to eligible transactions. For example a customer has sent a chec
50000US$. He has outstanding bills totaling 60000 US$. The set up in this screen tells how the amount of 50000$ will be appli
the transactions totaling 50,000 US$ out of the transactions of USD 60000.

Yes, once receivables are entered, they are able to be adjusted.

In the manual application process a user can choose any line(interest, charges, penalty etc.) while applying the receipt.

The report will have to be set up in EDW and can be tracked from there.

In oracle AR receivable creation and receipt creation are two independent processes. If a receivable is created and the custom
payment is due then a manual receipt can be applied or lockbox program can apply the receipt. We will have a discussion on C
the process around it.

We will be walking through this process in sprint 3.There is no program to be launched explicitly. The system does this based
following pre determined steps.
Unidentified receipt is not a miscellaneous receipt. A miscellaneous receipt is an income or expenditure arising out of non trad
business related activities. For example, if a customer's check failed to clear due to insufficient funds, bank may charge a fees.
does not send an AP invoice for these kind of charges and directly debits the account. These kind of activities can be recorded
negative miscellaneous receipt aka miscellaneous expenditure.

Unidentified cash cannot be returned without establishing the owner and the need to refund. The screenshot is for 1) searchi
the unidentified receipts and then 2) later applying one or more unidentified receipts to a bills receivable when the unidentifi
is ready to be applied to a bills receivable. This screen shot is not for refund of unidentified cash.
1) We will be providing an in-depth walkthrough of the screens during the CVS on 3/16.
2) We have a dedicated session on this topic in Sprint 3. The calendar is currently being finalized and we do not have a solidifie
date.
As stated during the CVS on 3/2, we will talk about this during the integration topics surrounding mLINQS in Sprint 3.
The BAS EBS will not have a tax engine, so this would likely continue to be a manual process as it is now. EBS can capture tax
payments.

EBS will generate the file and it will be sent in the same way that it is done today. 1099 is supported by standard EBS functiona
BAS does not include an HR portal; the business process that is used today to distribute this information will continue.

You can reference information guides from the CVS session, which distinguishes the difference between the configurations an
system setup vs. actual business processes.
The process will require similar levels of data entry as the current process. Each bureau will utilize the four standard format ty
that will be processed through PAM and ultimately confirmed by Treasury. The driver for payment processing will be paymen
type. A payment process request was a system walkthrough topic during the CVS session on 3/2 that identified different
requirements related to vendor and payment information.

A payment process request was part of the system walkthrough during the 3/2 CVS. Invoice batches can be referenced to be
pay those specific invoices in a batch. The payment process is scheduled and paid out per the payment terms.

No, a separate format is required for each file. This will be the same process as it is today.

The four types of payment files (CCD/CTX/PPD/IAT) are all admissible for processing disbursements to Treasury.

We are currently evaluating the integration impact of Connect Direct. The details will be discussed during the integration talks
Sprint 3. The Treasury Payment process will be seamless to the end user experience - the end user will not need to select anyt
related to the technical integration framework.

The payment format with the most flexible remittance advice would depend on what information needs to be captured as we
the type of payment.

The advantage of CTX is that it allows 999 addenda records for a total of 9,999 invoices per payment. You can use Corporate T
Exchange (CTX) to include complete remittance details and to cover multiple invoices at the same time. This format then gets
Treasury and produces the payment output files to pay vendors using electronic data transmission.

Payment terms are configured at the OU level and can be maintained at the invoice level.

A system admin. will be able to maintain the payment terms. The specific roles are currently being reviewed as part of the larg
RBAC discussions in conjunction with the OCM team.

Payment terms are configured at the OU level and can be maintained at the invoice level.

Oracle supports the US Prompt Pay act. There is functionality to adjust at the invoice level or at the supplier level.

No, net days would not be a required field in PRISM.

Payment terms will be defined in EBS.

This is captured in EBS from SAM, however, it is not transparent on the PO or the invoice on the EBS side.
EBS will generate a 1099 form; EBS will not be the system that provides access to recipients to access the 1099 output.

Yes, EBS will keep interest payment historical data.

EBS will start calculating interest from the "invoice received" date. This configuration was shown during the CVS on 3/2.

As part of the pre-deployment configuration, EBS will be configured to support the prompt pay requirements. The system will
the appropriate configurations in place to drive the required payment due dates.
The payment term can be adjusted to pay sooner for the vendor or the invoice, the standard is set to Net 30 days. The adjustm
should be viewed as the exception to the default.
Yes, you can setup for a matched document. Recurring invoice setup was a system walkthrough topic during the CVS on 3/2.

There is a configuration for both. There is no current requirement that has recurring invoices to be "posted as approved" or "n

The setup of a monthly/quarterly recurring invoice and the associated forms was walked through during the CVS on 3/2. A sp
calendar is created and the recurring invoice information is established in EBS.

Yes, recurring invoices can be set for matched documents. The obligation would have to be identified in the recurring invoice s
to be able to reference the document.

There is a configuration to allow recurring invoices (like for utilities) to be approved. This is not currently a requirement, so th
need to be added.

The "Terms Date Basis" is the date that Payables uses as the payment terms start date when Payables calculates the due and
discount date for invoice scheduled payments.

Because interest payments compound every thirty days, we suggest you pay interest when it is due, rather than allowing it to
compound. Set the minimum interest amount low enough so that your interest does not compound, but not so low that you p
very exceedingly small amounts of interest on past due invoices.

Expense Interest Invoice Account. If you enable the Allow Interest Invoices option, you must enter an interest expense accoun
Payables posts interest invoice distributions to this account when you post to the general ledger.

Liability Interest Invoice Account. If you enable the Allow Interest Invoices option, you must enter an interest liability account.
Payables posts interest liability distributions to this account when you submit the Payables Transfer to General Ledger program
interest liability account is always used when interest invoices are automatically created during the payment process. Payable
not overwrite the interest liability account using your FlexBuild Method system option.

"Out years" to our team means future years beyond the current Fiscal Year. The interest rates tables will have those interest r
for all periods. Therefore if the invoice is not paid in future periods, it will leverage that interest rate. We will add the test scen
confirm the SLA impact where the interest crosses different FYs. The interest rate is based on the SLA (fund) of the original inv
EBS accounts for 365 days for Prompt pay; EBS does not currently accommodate lag days.

EBS standard functionality supports invoice tolerances by goods / services (percentages and amounts). The AP module houses
tolerance configurations. Tolerances are still being discussed, and we will be meeting internally with DMF members to get on
accord in terms of functionality within EBS as it pertains to tolerances.

Options include:
Maximum/Quantity Ordered.
Maximum/Quantity Received.
Price.

DNP is an interface topic that will be discussed during the integration discussions in Sprint 3.

Yes, supplier records would be the same for all bureaus. Will confirm the scenario where one bureau would issue payment wh
other bureau has flagged for DNP.

There is one supplier record, the updates would be maintained at the department level. To determine who would handle this
process that would need to be discussed between the Dept. and the bureaus. The discussion around these details for DNP wil
continue in sprint 3.

We have DNP as part of our integration discussions during Sprint 3.

We have DNP as part of our integration discussions during Sprint 3.

We have DNP as part of our integration discussions during Sprint 3.

Yes, the DNP data call went to the bureaus, but the names of the individuals who contributed were not included in the data ca
response.

This data call requested each bureaus current business process for receiving DNP data today.
Telecom and UPS are not currently integration points, however, during Sprint 3 we will get into more details surrounding the fl
data between interfaces.

Yes, each bureau will be responsible for processing their disbursements.

We are planning to utilize Sprint 3 to discuss the Integration topics.

All invoices must be approved before payment, so approval during the payment process would not be a BAS to-be scenario. T
no way to select an invoice for payment that has not already been approved.

Could NOAA please provide more details on their current business scenario that would require payments to be approved durin
payment process?
Oracle has system checks and subsequent error messages that are in place to prevent the disbursement file from paying out.
Reporting is a topic in Sprint 3 where we will discuss the many different types of reports per workstream. We have included th
negative test scenario where there is a hard carriage return in the invoice number that prevents PAM acceptance.

If this is a clearing payment scenario, these are standard Oracle functionality. Supplier and Bank account information would be
in manually, select the invoices in the associated form, and select the invoices to be paid.

If it is a SAM vendor, the financial system will receive the international bank information. If it is a non-SAM vendor, there will
business process to accommodate these updates to the supplier record. Sprint 3 will cover the Vendor management processe

EBS will not be tracking non-USD.

EBS will only use USD.

Yes, foreign currency is currently out of scope for BAS.

The 1099 solution for BAS will be the standard across all bureaus.

The to-be reconciliation will be a manual process, much like what is done today.
Invoice created (PM003). Notice when Invoice is created, the Item’s Release Flag (R) is set to ‘Y’. This means it’s ready to be se
via the PM102 to Release Invoice for Payment.

Run PM102. Running PM102 will look at all invoices that are ‘released’ for payment. It will assess interest, penalties, holdbac
withholdings, etc. as applicable. In this case, we will get a penalty to the above invoice. This is similar to the validation process
is run before approvals (Before available for payment)

The next step is to run the PM103 which generates a payment schedule: - PM103 is similar to the Payment Dashboard process

Once Treasury pays the vendor, the ‘Accomplishment’ is recorded in CBS on PM005: = this is Treasury Confirmation

All invoices must be approved before payment, so approval during the payment process would not be a scenario that would c
in the system. There is no way to select an invoice for payment that has not already been approved.

Could you provide more details on your current business scenario that would require payments to be approved during the pay
process?

There is the Payment Instruction Treasury Symbol Listing report. This report will list all the treasury symbols and their respecti
payment totals for a selected payment instruction.

The formats presented during the CVS on 3/2 are all approved payment formats for submission to Treasury. Within EBS, the b
will determine the format to use based on the vendor type.

We would need to understand what other interfaces are required for NOAA other than the ones shown. There may be other
interfaces included that the integration team is looking into. We are discussing the impact of APSI-related interfaces; details w
flushed out on all BAS interfaces in Sprint 3.

IPAC Payments will be discussed in Sprint 3 in G-invoicing. Non G-Invoicing IPACs will also be featured in Sprint 3.

ASAP/Grants is still being internally discussed on the integration side of things. More details to follow in Sprint 3 - 4.

EBS has the standard IAT payment format to submit foreign payments to PAM for processing.
Sunflower integration will be discussed in Sprint 3. Specific EBS Data will be shared with SF such as PO award number and supp
project information. If there are specific data elements that need to come back to EBS - these should be highlighted in future S
sessions. These will be configured as DFFs if they do not map to COTS-available field.

This diagram was a relational concept between the interfaces and how they are projected to interact with each other. We
understand that DNP is not a full-fledged interface with an integration point to your financial system, however, it is still import
show that the data will be present and impact BAS.

This is not an all inclusive list. Integration will be further discussed in Sprint 3

IPACs will be discussed in Sprint 3.

ASAP will be part of future discussions in Q4 (Sept. 2021).

We took note of FOMF during the Payments CVS on 3/2 and are discussing details of the data flow in preparation for integrati
in Sprint 3.

We took note of FOMF during the Payments CVS on 3/2 and are discussing details of the data flow in preparation for integrati
in Sprint 3.
As the integration team solidifies the details of the data flow and building of integration points, there will be more detailed rev
to come in future Sprints.
Yes, EBS will be accommodate wire transfers as a payment method.

Based on the data call sent to the bureaus, these values will be configured into the system and shown once completed.

The Treasury-given rate has been configured in the system, per the bi-annual release.
Standard EBS functionality allows for 3 levels of discounts after a given number of days. Discount terms are only configurable a
payment term level and not the document type.
A data call was issued to the bureaus for the Payment terms in January. If there are additional payment terms, please provide
so we can add to the configuration baseline. In the future there will be a process to incorporate new configurations as part of
O&M process.

Yes, the current value of funds can be entered into EBS.

Yes, the discount rates can be overridden, however, they are established at either the Supplier site level or the Operating unit
not the document type level as received by the data call information. We will track this as an outcome for future discussion as
incorporate future e-invoicing requirements.

We are still working internally to identify a confirmed recommendation for discount terms, which we will discuss in Sprint 3.
IPAC Payments will be discussed in Sprint 3 in G-invoicing.

ASAP/Grants is still being internally discussed on the integration side of things. More details to follow in Sprint 3.

EBS has the standard IAT payment format to submit foreign payments to PAM for processing.

APSI is one of the topics that is still under internal review as today's capabilities are likely parallel to the BAS applications. APSI
DOC-specific feature, so the BAS support will mirror the same sort of capabilities but will leverage the BAS Core Apps function
development team is working on this and will address in Sprint 3.
Yes, the user may select other payments terms from the configured list.
The end user may select other payment terms from a seeded list, but they will not be able to add custom discount terms. We
received and are reviewing the discount term data provided and are taking them into consideration. Discounts will not be add
during the payment process; all of this update will happen on the invoice entry.

As part of the to-be process, the DOC standard invoice entry will review what date should be used for this field and how that
supports the prompt pay. The Invoice Workbench has the Invoice and GL Dates - so the Invoice Date will be what starts the clo
Prompt Pay. If this date is unknown, the same business process that is used today would be potentially followed in the future
where that date would be entered in the invoice date field.

Yes, the default configuration will be set to Net 30 for PP.

Reporting will be discussed in Sprint 3. We would also like to understand if there are specific late reason codes the bureau is
particularly interested in having shown via report.

Yes. The default for all Recurs can be set as either auto-approve or not approved. From the meeting conversation, the
recommendation is to set the default to not approved. The Recurs that need to be set as auto-approve can be set up for each

Yes, the default for all Recurs can be set as either auto-approve or not approved. From the meeting conversation, the
recommendation is to set the default to not approved. The Recurs that need to be set as auto-approve can be set up for each

Yes, the increase can be set as a dollar amount. A specific date can be called out in the special calendar.

EBS validates all the information entered into the payment process request against the approved invoice and vendor data
information. EBS will validate information such as ALC, banking, and supplier details prior to payment file formatting. The erro
messages will be produced in real time as part of the payment process. They must be reviewed and corrected prior to the pay
being completed. These are COTS error messages that will make sure that all the relevant data to support PAM, etc. are popul
interface correctly.

Some standard errors include:

- Insufficient Funds
- Invalid Credit Card/Bank Account Number
- Duplicate Order Identifier

ALCs are still being discussed and more information to follow related to impacts from G-Invoicing and federal reporting. We ar
working with the larger DOC group to understand next steps. More information related to ALCs will be discussed in future Spr
Yes; the certifying officer will still need to follow the business process outside of the system (similar to what is done today). De
surrounding the SPS interface and the associated data flows will be discussed during the PAM/SPS session in Sprint 3.

EBS will only process USD transactions.

The SPS Schedule Upload 440 File Format for Government-wide Accounting Reporter Only, Version 1.0 file format is now
accommodated in EBS. Details surrounding the SPS interface and the associated data flows will be discussed during the PAM/
session in Sprint 3.

BAS supports commitment accounting; We have a session on SP3, and P-card/T-Card/F-Card scheduled for discussion in Sprint
will collaborate with the EBS development team to provide a recommendation for how commitments will be transacted in this
interface. We plan to review and discuss the SP3 interface as it relates to the authorization, voucher process and the resulting
accounting.

ALCs are still being discussed and more information to follow related to impacts from G-Invoicing and federal reporting. We a
working with the larger DOC group to understand next steps. More information related to ALCs will be discussed in future Spr

Yes, a bureau can kick-off its payment run for the day independent of other payment offices.

Invoice validation is the process that will do internal audit / validations of the invoice information. An invoice must be validate
without any system holds prior to being considered available to be paid. There will be review as part of the invoice approval
hierarchy that happens prior to payment.

Reporting capabilities will be flushed out during Sprint 3, but here are a few reports pertaining to validate payments before re
to PAM:

Payment Exceptions Report - Lists payment exceptions

Payment Audit by Voucher Number Report - to review payments with assigned sequential voucher numbers.

Payment Register report - to review payments created for each bank account

Missing Documents Report - to identify any payment documents that you have not accounted

Payment Batch Control report - to review detailed information about the payments printed in one or more payment batches.

All invoices must be approved before payment, so approval during the payment process would not be a BAS to-be scenario. T
no way to select an invoice for payment that has not already been approved. Thus an invoice will not be paid or submitted to
it is entered incorrectly; it will not pass system checks. The COTS PAM file formats will pass PAM edits based on their layout;
however, we need to understand non-system reasons why it would fail. There are also internal payment edits that are applied
each payment file to intervene prior to PAM submission (Document Payee Bank Account Type is invalid, etc.). Oracle prevents
payment to proceed to PAM if it doesn't pass required edits. If there are accounting issues (IE need to transfer the costs, etc. t
does not impact the actual payment to vendor), there will be supporting transactional adjustments and corresponding accoun
entries to support that, aka a clearing invoice, etc.)

We would need to understand if there is a unique scenario that would require you to make edits following PAM review.

The payment process (to push payments out the door to PAM) is still being reviewed in conjunction with the overall RBAC. Mo
details to come in Sprint 3 as this is confirmed.
Yes, payment terms other than Net 30 days can be configured with different discount terms. We are still in the process of iden
which discount terms are to be included in the final configurations and more details will follow in Sprint 3.

Yes, EBS allows pre-payment invoices as standard functionality.

Yes, the configuration for estimated accruals is housed in the AP module setups, however, the actual recording of these estim
accruals will be in the Projects module.

If there are manual journal entries that are directly entered in the General Ledger to support year end processing, that would
the GL module.

In this context TAS = Treasury Account Symbol. The TAS is derived from the FUND value that is included in the detail accounti
string (ACS) on the transaction. For G-Invoicing integration, the key data point is the TAS (for both requesting and servicing ag
which is why TAS was called out in the diagram.

For IAAs where the DOC/bureau is the Servicing Agency, the GT&C and Order will be interfaced from G-Invoicing to the EBS Pr
module.

For IAAs where the DOC/bureau is the Servicing Agency, the GT&C and Order will be interfaced from G-Invoicing to the EBS Pr
module. Full mapping of transactions from G-Invoicing to BAS will be provided as the Oracle solution is finalized.

The 7600A form can be generated from the Treasury G-Invoicing system, based on data entered by both the requesting and se
agencies. There is no capability to print the forms within EBS at this time.
For IAAs where the DOC/bureau is the Requesting Agency, the Order will be initiated in BAS. The supplier and terms will be en
on the order, based on data stored/configured in BAS, and this data will be interfaced to G-Invoicing. The ALC on the supplier
used by G-Invoicing to determine the servicing agency.

Yes, the TP Main Account, a component of the TP TAS, will be interfaced from G-Invoicing to EBS. The TP TAS will be entered b
trading partner agency, regardless of whether the DOC/bureau is the requesting or the servicing agency.

This question has since been addressed through the EDW Requirements Grooming sessions - during demo EDW will show how
should be joined to meet reporting needs.

Descriptive flex fields identified during the BAS Common Solution phase and/or bureau implementation phases will be include
the EDW to support the development of reports by EDW Power Users. Hence, it is crucial for those additional data fields to be
identified in the future CS Sprints related to Reporting and Analysis. In addition, analysis will be performed by the BAS Team to
determine reports that are required in "real time" to confirm the reporting source for that required data.

There are close to 1,000 reports available in EBS - not all may be relevant to what DOC needs. To determine relevant reports, w
have requested that the DMF identify their current top 10 reports for each process area. Based on that, the BAS Team will ide
relevant EBS reports to provide description, parameters, data elements, export options, and sample report with mock data. If
is no corresponding EBS report, the BAS Team will assess alternative solutions (including enabling development in EDW by Pow
Users). EBS reports and any alternative solutions will be reviewed by the DMF in the corresponding CS sessions related to repo

Data refresh in the EDW will be batch, not real time. The EDW data refresh schedules for Core Applications and other data sou
(applications that provide data directly to the EDW, e.g., WebTA) will be identified in FY22.
This question has since been addressed through the EDW Requirements Grooming sessions. Yes, there will be a process to ens
this information is captured.

Standard Reports will have a variety of parameters for each report. Many reports can be run by fund as well as bureau.

As stated during the session on 2/4, we will discuss this topic in the future during the system interface sessions.

Some AR reports can be run for reimbursable agreement bills / invoice types. If more info is required on reimbursable agreem
those have to be run in the Projects module.

No. The seeded AR reports cannot be run with reimbursable agreement number as parameter. Please see Project reports whic
data on reimbursable agreement as well as revenue/bill/expenditure data. This may be discussed in the upcoming projects ses

For many reports transaction number low, high are available as parameters.

Project code is not a standard parameter for AR reporting. This is something we will need to have a further discussion on. The
reports in the Oracle Projects module that may suit your need. If it does not, the BAS Team will perform analysis to determine
to best meet the reporting need.
No, this is not standard in Oracle EBS. Please note that the RBAC will support segregation of data by bureau. Therefore, the RB
allow only that specific bureau's data to be returned for a specific report.
Task Code is not a standard parameter for AR reporting. This is something we will need to have a further discussion on. There
reports in the Oracle Projects module that may suit your need. If it does not, the BAS Team will perform analysis to determine
to best meet the reporting need.
No, this is not standard in Oracle EBS. However, we are having additional conversations with the Core Apps team on how to
accommodate this data element.
The common report parameters will not be available on every report. However, there will be a series of report parameters on
report.
As stated during the session on 2/4, there is not going to be a required mapping effort from CBS to EBS due to the limitation o
duplicate numbers and all project codes will be unique.

Yes, this information was shown during the CVS on 3/11 CVS.

In Oracle there are flex fields where any type of information can be captured (i.e. voucher #, deposit ticket #). Reports can be
using the info on these flex fields. Additional discussions related to CARS reporting are scheduled for Sprint 3. Based on the
discussion, the BAS Team will determine how this reporting requirement will be met.

Additional TROR discussions, including aging buckets, will be scheduled for Sprint 3, where reporting requirements will be iden
From there the BAS Team will determine how this mandated reporting requirement will be met.
Additional TROR discussions will be scheduled for Sprint 3, where reporting requirements will be identified. From there the BA
Team will determine how this mandated reporting requirement will be met.

Yes, what has and has not be posted to the GL will affect the output data of the report because those transactions in the syste
be pending. All Oracle EBS reporting data is real-time.
To date, we have had a conversation with NOAA to capture those QR101 reports. We asked for the ones most frequently run a
found that standard Oracle EBS accounts for majority of them. In cases where there is not an Oracle EBS report that maps, the
Team will perform analysis to determine the how to best meet the reporting requirement.

We provided our top ten list of reports that provide an excel output. In cases where an EBS report(s) does not have Excel outp
CSV or TXT), EDW Power Users may be able to build a report that is exportable to Excel. If reports that require real-time data
available in Excel (or CSV, TXT format), additional discussions and analysis will occur to determine if this reporting need can be
EBS.

1)The TROR report is a standard report in Oracle Receivables. 2) BAS Core Apps has identified the treasury mandate on this an
will have further discussions on TROR in sprint 3.

Depending on the report, Organization (a segment of the overall ACS) could be available for specific reports. The Organization
will be representative of that value in the ACS Org Code Value. Certain reports will allow you to select certain ranges of Org Co
one specific value. As the Org Code is a part of each ACS line of accounting, this will be a data element available at the transac
level in EDW.

For all requisitions that start in PRISM, the associated accounting events for the commitment will be saved in EBS in real time
time of requisition approval in real time (after a funds check). The line of accounting / POET attributes will be available on the
requisition record in PRISM; the associated lines of accounting will be available in the financial system of record (EBS). EBS will
include that impact for the commitment values in the overall financial balances, etc. This information would then be included
of the EDW feed.

The BAS PMO will review this request.

This response was shared in recent BAS Program Bi Weekly Update for CNN

Question has been documented as a critical concern, the team is working with Accenture to bring this forward as part of the P
conversation. There are other factors influencing this such as G Invoicing, so given those dependencies this may slide to sprin
as needed.

Response to be provided on ACS Part 1 question set.

Response to be provided on ACS Part 1 question set.

Response to be provided on ACS Part 1 question set.

Response to be provided on ACS Part 1 question set.

Response to be provided on ACS Part 1 question set.
Response to be provided on ACS Part 1 question set.

Response to be provided on ACS Part 1 question set.

The org code workbook is not intended to be a final list but rather the methodology that will be used. The only change to the
will be appending bureau code to the front end of existing codes to ensure the code is a unique value in the system. The bure
will work with the PMO at the point of conversion to determine which Org code values need to be brought forward into EBS.

The org code workbook is not intended to be a final list but rather the methodology that will be used. The only change to the
will be appending bureau code to the front end of existing codes to ensure the code is a unique value in the system. The bure
will work with the PMO at the point of conversion to determine which Org code values need to be brought forward into EBS.

The topic of BOPs will be introduced during the Budget Entry meeting on 2/24 with further more detailed conversation include
the Projects meeting on 3/31.

Funds Control will be discussed in the Budget Entry session on 2/24.

Cost allocation process conversations are ongoing, the next follow up meeting with NIST is on 2/25. As this conversations con
and the processes are defined, we will look at impacts to use of current object class codes and what if any changes are require

A workgroup has been formed to analyze all of the values in the workbook
A workgroup has been formed to analyze all of the values in the workbook
A workgroup has been assembled to discuss the object class code workbook. Past analysis is a reference, but may not be in lin
future direction.
As discussed during the meeting, OMB standard is 3 spaces and the 4th space is being reserved for future use in line with CGA
guidance.

The PMO is starting a workgroup to clean up the existing object class workbook to isolate the exact number of unique object c
codes needed. When that is complete, further discussions will be scheduled with the bureaus on how spaces 5-7 should be
populated.

The PMO sent out a data call on 2/25 to the bureaus to document current use of sub accounts. When that feedback is receiv
analyzed it will be discussed in follow up ACS meetings to occur in Sprint 3.

This will be handled in both the conversion and training strategies that will be developed in future sprints.
This will be further discussed as we analyze the crosswalks across the bureaus. There will be future sessions to discuss
standardization for internal sub accounts. A data call was sent to the bureaus on 2/25 to gather this information for analysis.

This will be further discussed in the Reporting sessions. We will cover standard PTR reporting's in Sprint 3 which will give you a
of how standard BAS reports will provide information. (e.g. Trial Balance, Accounts Summary)

A data call was sent out to the bureaus on 2/25 to get current CBS Production USSGL Accounts/Sub Account data. BAS team w
analyze this, and there will be a future session to cover the approach for USSGL segment with sub account codes.

This will be further discussed during Budget Follow Up meeting on 2/24.

All segments' data set will be common across the bureaus, but there will be data controls (e.g. Data Access Sets from Sprint 1)
place to limit bureaus to their respective values for these segments.

These 3 positions will be shared across DOC. Further analysis and discussion will be held to clean out the crosswalk and consol
the values based on usage of the current values for similar scenarios. This will help standardize and narrow down the Object C
values.

We will have further discussions on Object Class in the follow up sessions. We will cover further scenarios in detail to understa
requirement better.

This will be further discussed during future Object Class sessions as well as during conversion activities.

Until the ACS is final and confirmed, it is not possible to answer questions related to the update or maintenance of bureau lev
policies.

This topic will be covered during the session on 3/31.

Please resubmit this question with additional information, there is not enough information here to respond.

PTR reporting will be introduced in Sprint 3. The setup related to entering/tracking cohort funds is currently under review ba
similar feedback received on question sets and during meetings. Will discuss open issues such as this at ACS follow up session
Sprint 3.

Please resubmit this question with additional information, there is not enough information here to respond.

Program Code definitions are under review. An initial meeting is scheduled between the BAS PMO/DOC Office of Budget/Bure
Budget attendees on 3/11 to discuss progress to date and to align needs and expectations within the Budget community on th
of Program Code. Follow up sessions will bring in a broader audience as needed when these discussions are concluded.
Labor Processing and related business processes will be covered in Sprint 3.

This topic will be covered during the session on 3/31.

Given the outstanding questions around Funds Control we are going to repurpose the 3/25 meeting to do another deep dive o
Budget Entry and Funds Control topics to demonstrate additional functionality we were not able to cover in the first session. T
CVS will be moved to early April, and given that it will follow the 3/31 conversation on Projects the bureaus should then have a
better understanding of the full functionality around both Fed Admin funds control and additional funds control functionality
available through the Projects module.

There will be further conversation during the meeting on 3/25, we also understand that all of the bureaus are working through
content presented and will bring their feedback to that session.

Budget Authority Screen in Federal Administrator module in BAS EBS is equivalent to FM061 screen. This Budget Authority scr
will be used to process Appropriation transactions.

We will share an updated approach on how to track mandatory and discretionary funds during the session on 3/25.

This can be achieved. For example, we can record allotments at Program and ORG level and control the fund at Program level.

Yes, funds control for direct and reimbursable funding may be different. Specifics on funds control for reimbursable projects w
discussed at the 3/31 Projects session.

We will talk more on funds control in 3/25 as we do not have final decision yet. We can address this then.

With respect to uploading allotments we will do further research, but this may be a custom solution through WebADI function

The specific exceptions to funds control will be discussed at the 3/25 and 3/31 sessions.

Yes, the values will look like such. We will review this capability more in 3/25 session. The standard capability called Roll Up Gr
and Parent/Child hierarchy can be used to setup funds control at a particular level.

The solution for supplemental funding will be covered during the session on 3/25. This solution would be specific to suppleme
funding and we would have to work with Census to see if this is needed for your WCF breakouts or if you could meet your rep
needs through other methods.

Standardization of funds control will be set at a common level across the Department, there should be flexibility for a bureau t
apply stricter funds control as needed. In addition, at the Projects session on 3/31, functionality to apply funds control at a pr
level will be covered to show how Projects functionality can drive at a lower level for Reimbursables or other projects as need
An initial meeting is scheduled between the BAS PMO/DOC Office of Budget/Bureau Budget attendees on 3/11 to discuss prog
date and to align needs and expectations within the Budget community on the use of Program Code. Follow up sessions will b
a broader audience as needed when these discussions are concluded.

Budget Planning functionality at project level will be covered during the 3/31 session on Projects.

In addition at the session on 3/25 we will demonstrate how Program Code can use the roll up functionality. This should provid
greater context on how similar functionality can be applied to the Org Code as asked in this question.

For transfers between one Org to another, the standard capability called Reprogramming Transactions can be used in BAS. Th
transfer will happen at the allotment level. We can review this more on 3/25.
Waiting for feedback from NIST on more details on the nature of their supplemental funding
We will cover the BOP type functionality at the Projects session on 3/31 and can discuss whether there is an upload capability
that session.

With respect to allotments we will do further research, but this may be a custom solution through WebADI functionality.

This will be added to the content.

The team understands the given scenario and the connection between DEFC and Fund Codes. We will further analyze this, and
include to answer in the ACS follow up sessions.

The Mandatory or Discretionary attribute of Fund will be further discussed during the follow up sessions as the team is curren
analyzing this scenario.

The standard capability in BAS where you can configure your reporting codes will be leveraged to identify the disaster funds. W
further discuss the DEFC scenarios in the follow up discussions.

No action is required at this time. The main purpose of the workbook at this time was to illustrate the methodology using rea
We will work with the bureaus with live data after the methodology is finalized to ensure any cleanup or open questions are
addressed.

The BAS Program Code Level 5 and 6 are there for bureaus to provide the internal code and internal sub-code. This is where b
input will be needed. Level 1 - 4 is defined and managed by Department.

This will be further discussed with DOC Office of Budget and communicated to the bureaus accordingly.

The BAS Fund Values will be unique values as well. Each fund values will be linked to TAS in fed admin module to define appro
attributes for reporting purposes. Additional capabilities throughout the BAS system (e.g. SLA, Reimbursable Activities) will als
us to limit creation of more unique funds values for same main account, thus collapsing current CBS Fund Codes into less BAS
Code values.

Per the meeting handouts, BFY is defined as - The appropriation fiscal year of the fund when it was originally enacted.
The Mandatory or Discretionary attribute of Fund will be further discussed during the follow up sessions as the team is curren
analyzing this scenario.

We will be scheduling a working session with the bureaus and DOC Office of Budget to work through the coding methodology
ensure both DOC and bureau level requirements are met in the new Program Code values.
This information is included in the meeting materials from 1/25 and 2/16. The overview for the first 5 segments can be found
handout from the January session, and the overview of the last three segments is included in the 2/16 handouts.

We will be scheduling a working session with the bureaus and DOC Office of Budget to work through the coding methodology
ensure both DOC and bureau level requirements are met in the new Program Code values.

The new naming convention does collapse existing fund codes into less fund values, and we understand you would like more
visibility in how reporting is accomplished given this change. In sprint 3 we will begin to dive into reporting and how these cod
be used to drive your reporting needs. Further, there will be additional ACS follow up sessions to address any gaps identified
existing reporting requirements based on the new values.

We will be scheduling a working session with the bureaus and DOC Office of Budget to work through the coding methodology
ensure both DOC and bureau level requirements are met in the new Program Code values.

The capability of tracking of these elements and other like it will be discussed and demonstrated at the Projects session on 3/3

Project related information will be covered as part of the Projects session on 3/31. The integration between BAS ACS and
Project/Task will also be the focus of the discussion.

The PMO is working with CWT to make appropriate updates on the coding structure required to interface transactions from E2
EBS. It is understood that since NOAA will go live on EBS first that multiple solutions will need to be in place until all bureaus a
on EBS.

The definition was provided in the meeting materials. The obligations will be recorded against the year the funds were enacte
Specific questions/concerns can be addressed in ACS follow up sessions in Sprint 3.

Per BFY definition, appropriate BFY can be picked if using reapportioned funds for transactions. Funds will be reapportioned a
of the carry over process.

This question will be discussed at the 2/24 Budget Entry meeting, and may require further follow up in Sprint 3 as we continue
work through this scenario.

This would require further analysis/discussion. This can be a discussion point in individual bureau working session.

NOAA cost allocation discussions began on 2/19, and we are still in the investigation stage on this topic. Additional information
be shared once there is a deeper understanding on NOAA's current cost allocation processes and how they fit into EBS.
Adding additional attributes as part of BAS Fund Code (e.g. Direct/Reimb flag, BPOA/EPOA, Category) will allow standardizatio
the fund code across DOC bureaus, and also provide further details on what fund is being used at transaction distribution line.

Attributes such as Direct/Reimb flag, Apportionment Category will be part of out of the box capability in Fed Admin module w
you can distinguish funds. Further crosswalk discussions with individual bureaus will be held to understand such scenarios.

When entering a Journal Voucher/GJ the full ACS will be required, for transactions entered into the EBS modules there will be
functionality to derive the ACS based on the Project Task/Org/Expenditure Type combination that is entered.
The flex fields in the ACS string have been reserved for future requirements or mandates that are issued. At this time there ar
plans to use the DFF on the ACS string.

The system will be configured to meet all mandatory reporting requirements. As new requirements are identified they will be
incorporated into the DOC coding structure.

This topic will be addressed in Sprint 3.

There is a standard capability to record DEFC for Fund/Task for reporting purposes. This will be discussed further in follow up
sessions.

This is a change from CBS functionality and the current use of FCFY. It will be flagged as a training topic that needs to be addre
moving forward.

NOAA cost allocation discussions began on 2/19, and we are still in the investigation stage on this topic. Additional information
be shared once there is a deeper understanding on NOAA's current cost allocation processes and how they fit into EBS.

In the fund value for X year funds XXXX will be entered to denote the beginning/ending period of availability. Funds would be
available in the current year and future years if there is carryover. However, the carryover values will be flagged with a BFY of
year the funds were initially enacted.

Yes BFY is part of the ACS string and would be included on commitments.

Yes, the funds would retain the identity of the year the funds were enacted so there is traceability of the funds from enactmen
through final expenditure in whatever fiscal year they are obligated.
No, the funds would retain the identity of the year the funds were enacted so there is traceability of the funds from enactmen
through final expenditure in whatever fiscal year they are obligated.

There would be multiple ACS lines to record the obligations across the various BFY's. Having the different buckets of money
identified should provide clarity on the different years of funding associated with the transaction.
This will be discussed in the appropriate conversation questions in future sprints.

BFY is required ACS element. Specific EDA examples can be discussed in greater detail in ACS follow up sessions as needed.

NOAA cost allocation discussions began on 2/19, and we are still in the investigation stage on this topic. Additional information
be shared once there is a deeper understanding on NOAA's current cost allocation processes and how they fit into EBS.
We will be scheduling a working session with the bureaus and DOC Office of Budget to work through the coding methodology
ensure both DOC and bureau level requirements are met in the new Program Code values. Specifically the PPA information ha
provided by DOC Office of Budget and would be reflected in segments 2-4 of the Program Code Workbook.
We will be scheduling a working session with the bureaus and DOC Office of Budget to work through the coding methodology
ensure both DOC and bureau level requirements are met in the new Program Code values. The PPA information provided by D
Office of Budget is leveraged for BAS Program Code.

This will be part of the future session to review maintenance/business process model.

This topic was covered in ACS Part 2, but the basic principle on Org Code was to leave the current Org Code structure in place.
Further, we have discussed appending the new Bureau Code information in Org Code through integration to minimize any cha
to HR Connect and/or NFC. Those conversations are ongoing.

The team understands the given scenario and the connection between DEFC and Fund Codes. We will further analyze this, and
include to answer in the ACS follow up sessions.

The Mandatory or Discretionary attribute of Fund will be further discussed during the follow up sessions as the team is curren
analyzing this scenario.

Please see the BAS ACS and Federal Elements matrix sent out on 12/4. The matrix crosswalks values from CBS screens to EBS
equivalent. Any follow ups can be covered in ACS follow up sessions in Sprint 3.

The new naming convention does collapse existing fund codes into less fund values, and we understand you would like more
visibility in how reporting is accomplished given this change. In sprint 3 we will begin to dive into reporting and how these cod
be used to drive your reporting needs. Further, there will be additional ACS follow up sessions to address any gaps identified
existing reporting requirements based on the new values.

Projects functionality will be discussed during a session on 3/31. In addition to this there are plans to hold a Program Mgr. leve
briefing prior to this session to share information prior to the larger meeting to identify any questions or concerns prior to the
briefing.

Agreed the new naming convention does collapse existing fund codes into less fund values, and we understand you would like
visibility in how reporting is accomplished given this change. In sprint 3 we will begin to dive into reporting and how these cod
be used to drive your reporting needs. Further, there will be additional ACS follow up sessions to address any gaps identified
existing reporting requirements based on the new values.

Noted that some values may be incorrect. At this time no edits are needed. The purpose of the workbook at this time was to
illustrate the methodology, when final values are created we will work with the bureaus to make sure all are set up correctly.

Feedback is noted, we will be scheduling a working session with the bureaus and DOC Office of Budget to work through the co
methodology to ensure both DOC and bureau level requirements are met in the new Program Code values.
Feedback is noted, we will be scheduling a working session with the bureaus and DOC Office of Budget to work through the co
methodology to ensure both DOC and bureau level requirements are met in the new Program Code values.
The capability of tracking of these elements and other like it will be discussed and demonstrated at the Projects session on 3/3
addition, the ability to enter budgets will also be covered in the 3/31 session.

At this time no edits are needed, we will schedule the meeting to follow up on this topic. The purpose of the workbook at this
was to identify the methodology, and we will work through open questions with bureaus and Office of Budget before working
final values.

We are anticipating a follow-up meeting with NIST Budget, DoC Budget, and BAS team.

There will be a JV preparer and approver. As today, if you wish to have additional review outside of the system that should no
issue.

Any directly entered Journal Entries with category of Manual Entry or even Accruals, can be reversed manually using Reverse b
on Journal Entry screen. This can be discussed further during 3/1 meeting.

If these entries are entered directly to GL, then it is a manual entry with the source being manual and category as Accrual. So,
is agreement to use auto reversal for accrual, these entries will be auto reversed per Journal Reversal Criteria Set.
The PMO has identified current SLT business processes as a high priority topic. A data call documenting current SLT usage was
completed in January, and the PMO is currently working through the list to understand how they correlate to the WebADI fea
The bureaus can expect further discussion on this topic in Sprint 3 as well as categorizing the different purposes of the SLTs to
(expenditure transfers, subledger activity, etc.).

DLAs and DLCAs will be researched in greater detail to determine if they are appropriate for WebADI or if there is module spec
correction processes in the PTP related screens. The Phased Deployment Year will include the related SDLC activities for Web A
All corrective actions should be performed in the source module. This can be discussed further by transactions in subledger m
to review what corrective action steps would need to take.

As discussed in this session and others previous the need for GJ's in EBS should be reduced comparative to CBS because many
those done today would be pushed back to the specific modules. With a smaller population of GJ's, the expectation would be
the accountants and approvers that are preparing and reviewing these entries should be familiar with USSGL entries.

With the exception of the OTC session on reporting in Sprint 2, all other modules are scheduled to discuss reporting in Sprint 3
BAS functional and EDW teams will be working together with bureau input to document high priority reporting needs, validat
needs against available EBS reports, identify gaps, and where appropriate escalate to EDW workstream.

We would need more context to appropriately answer this question. It can be addressed in Journal Approval Workflow sessio
3/1 during Q&A.
Yes, if Journal Approval Criteria Set is used, accruals entries will be by default scheduled for reversal per parameters defined in
criteria set. We will review Journal Approval Criteria Set capability in 3/1 session.

The configurations discussed during the 2/10 meeting will be reviewed with the DMF for decision at the JV Approval
Workflow/Reversal CVS session on 3/1. There will be a review during that meeting of the key concepts, and the bureaus will b
to ask additional questions at that time.

All transaction corrective actions for AP related transactions can be done in AP module in BAS. This was initially discussed in Sp
(discard line feature). Sprint 2 will talk about Payments and adjustment invoices for clearing entries. This can be discussed furt
PTP workstreams during their future sessions (Sprint 4) to understand details around specific scenarios and month end reconc
efforts.
NOAA cost allocation discussions began on 2/19, and we are still in the investigation stage on this topic. Additional information
be shared once there is a deeper understanding on NOAA's current cost allocation processes and how they fit into EBS.
Yes. A supervisor can be set up as both a preparer and approver, but like your current business rule they cannot be both on a
transaction. In addition, specific roles and associated rules (RBAC) will be discussed in greater detail in future sessions.

When it comes to the limits, it is set by Ledger, so the Service Set concept will not be applied. Given this, there won't be a prob
leads sharing multiple bureaus. Also, there can only be one limit setup per employee, so if an approver has different threshold
can be setup with their highest threshold so that they can process approvals.

The Approver will receive a notification for approval under the Worklist page of their user account. The email notification can
setup to receive notifications to email.
The line number represent the sequence in which the journal entry lines appear in reports.
The system allows for different types of attachments. Using the attachment feature is optional, and will be a bureau specific d
based on the value of keeping the entire record in a single place.
The session on 3/1 will include system walkthrough of these processes.
The concept of Transaction Code does not exist in this newer version that will be used for BAS Oracle EBS. Instead, the Subled
Accounting Capability is leveraged to post accounting events using standard GL accounts defined by Treasury for each specific
accounting event that occurs through subledgers/modules.

We will review this further in 3/1 session.

The PMO has identified current SLT business processes as a high priority topic. A data call documenting current SLT usage was
completed in January, and the PMO is currently working through the list to understand how they correlate to the WebADI fea
The bureaus can expect further discussion on this topic in Sprint 3.
The Credit/Debit fields on Journal Entry screen are 36 character long each.
There is no Financial Planning module in scope for BAS. Could you please give more specific scenario on what types of investm
record you are talking about?
Yes, there are standard reports for Journal Entry details. These standard PTR reports will be discussed during Reporting session
Sprint 3.

We would have to analyze this further. This can be topic of discussion in Sprint 3 Year End/Month End processes discussions.
This will be discussed in Sprint 2 sessions occurring on:
1/14/2021
2/24/2021
3/25/2021
BFY was discussed during the 1/25/2021 session and will continue to be part of the ACS review discussion. The appropriation fi
year of the fund when it was originally enacted.
No, BFY should not change so it would not be past the period of availability.
This example doesn't provide clarity on the expiration of DOE funds. However, when establishing the reimbursable agreement
projects module the period of availability will be defined.

There cannot be any additional fields.

Servicing offices will only see applicable codes for their service set.

CVR discussions were originally held as part of Sprint 1. The CVS confirmed specific rules related to non zero values. As part of
discussion, the DMF discussed that we would review the bureau requirements during the Phased Deployment years where ad
restrictions could be defined where the bureau can define specific values to be considered.
Sprint 3 will cover the Year-End Close Process
CVR discussions were originally held as part of Sprint 1. The CVS confirmed specific rules related to non zero values. As part of
discussion, the DMF discussed that we would review the bureau requirements during the Phased Deployment years where ad
restrictions could be defined where the bureau can define specific values to be considered.
There will be detailed conversations beginning in January through March on the EBS ACS

No, the Project / Task will not be a part of the Accounting String. There is a projects module where the project will be maintain
The future discussions related to ACS and Project / Task will show how the ACS and Project Task will work together.

The role of Project/Task will be discussed in the ACS Review Part 2 and 3 on February 16th and March 31st. The components o
ACS were discussed at the 12/10 PTR-Ledger Overview meeting, see BAS - Federal Accounting and Federal Elements Matrix" A

No, BAS will be a single configuration with governance at the Department level. The CVR will be part of the configuration base
prior to the phase deployment. The Common Solution will focus on the requirements for the CVRs to support the one set of
configurations.

Only for manual general journal entry. The other modules will use the subledger accounting method, events, and correspondi
posting logic to drive general ledger entries. The recommendation will allow the users to select the appropriate task and proje
information which will then create the appropriate accounting (including the correct USSGL). More discussions related to the
account generation and ACS string based on the Project / Task configurations will be discussed in March 2021.
No, from slide 7 in CVR presentation, CVR's will impact subledger accounting transactions interfaced to the GL (PO, AP, PA, AR
any external accounting transactions interfaced to the GL such as Sunflower, Prism and any manual journal entries. From the D
feedback, they were not prepared to confirm the CVRs beyond the four recommendations. We can revisit this after the ACS
discussions when people have more information related to the overall ACS impact.
System will require you to enter all required fields. For fields that are not required, null would be acceptable. A yellow field in
that it is a required field, a white field is optional. Zeroes can be entered if it is a valid value for that field.

The components of the ACS were discussed at the 12/10 PTR-Ledger Overview meeting, see BAS - Federal Accounting and Fed
Elements Matrix" ACS tab.

The proposed fund code naming structure will be discussed during the ACS Review-Part 1 on January 25th. The proposed Org
naming structure will be discussed during the ACS Review Part 2 on February 16th.

This refers to the data access controls/security groups. Please reference presentation from meeting on 12/10/20 -BAS CS PTR
Overview 2020 1210.
The specific data entry requirements will be covered during the appropriate workstream conversations. (OTC, PTP, PTR, ATD).
manual transaction entry, the to-be business process would include which data elements are required to be entered by the en
users. BAS to be process will include which project / task attributes should be entered (which will pull in the appropriate fund
information based on the DOC configurations).

Yes, confirmed during session on 12/1/20.

Yes, confirmed during session on 12/1/20.
We are tracking CWIP impact as an outcome from Sprint 2. We will evaluate the project schedule impact and plan further disc
during Sprint 3 - 4.

Based on who you currently cross-service, BIS and EDA would be included in the NOAA service set.

Yes, the NOAA Service Set I just the 3 bureaus.

No this is going to be determined during the Common Solution phase and will be configured. Generally it is a one time set up a
be modified
Data if a bureau
Access sets is added
are defined or removed.
by the OU (where OU is currently configured as NOAA,NIST,CENSUS). Be definition the Data Acce
Control is defined by the bureau and would have its own configuration (NOAA can only see NOAA related data, etc.). The appr
was to leverage Bureau segment to create data segregation by creating 3 sets because of the current Servicing setup they hav
Bureau segment helps creating those three buckets and putting rest of the bureaus in appropriate servicing bureau buckets. S
NIST Access Set/Responsibilities will have data from ITA, MBDA, OIG, OS and so forth.
Service set is the bureau and any others that are included in the set up and any others that are cross serviced by that bureau.

PRISM will have the appropriate access to sites. PRISM data is available based on the user account profiles which grants acces
specific site data. When that data is integrated, the Oracle data access control will follow the configurations for view only for t
commitment and obligation data.

The chart of accounts in EBS is equivalent to the GL chart of accounts in CBS.

Discussions related to USSGL will be a part of the Sprint 2 ACS reviewed (Session 2)

There is no expiration date on segregation itself. In an event of service providers change, the values will need to be updated to
sure they roll up to correct bucket of data segregation. This will be part of maintenance process.

Servicing bureau can see all data and transactions for their service set.

The proposed org code structure will be discussed during the ACS Review - Part 2 on February 16th.

The BAS team is currently analyzing the ACS values to determine an approach for PPA reporting. This approach will be shared
the bureaus in the ACS Review-Part 1 on January 25th.
USSGL will only be required to be manually entered for manual general journal entry. The other modules will use the subledg
accounting method, events, and corresponding posting logic to drive general ledger entries.
We are currently discussing on this topic internally. Once the solution is identified, this will be briefed with BAS PMO and rolle
to DMF as appropriate.

The BAS PMO is currently working on documenting all current use cases for SLT and expects to have further discussions intern
and with the bureaus on how the EBS ADI upload functionality would potentially replace current SLT usage across the Departm

In BAS, Activity is tracked via Program segment from BAS ACS. There will be OMB Program Activity to BAS ACS Program Code
crosswalk made in the system. Project/task is linked to Program and consequently activity. Therefore, Activity Code represent
on BAS Projects Module as it will be linked to BAS ACS Program.

The proposed org code structure will be discussed during the ACS Review - Part 2 on February 16th.

The proposed org code structure will be discussed during the ACS Review - Part 2 on February 16th.

The proposed object class code structure will be discussed during the ACS Review - Part 2 on February 16th.
There will be in depth conversation on each component of the ACS in the coming months.

ACS Review - Part 1: BFY/Fund/Program/USSGL/Agency ID on January 25th

ACS Review - Part 2: Org/BOC/Project-Task on February 16th
ACS Review - Part 3: Project-Task on March 31st

Currently there is a growing list of Acronyms for BAS purposes available on the Tools and Resources section of the BAS website
terms of training materials or other resources, those will be part of the Phased Deployment year work products. In addition to
each vendor application has resources to help define fields that we will leverage as part of the product offering.

The modules will use the subledger accounting method, events, and corresponding posting logic to drive general ledger entrie

The role of Project/Task will be discussed in the ACS Review Part 2 and 3 on February 16th and March 31st. The components o
ACS were discussed at the 12/10 PTR-Ledger Overview meeting, see BAS - Federal Accounting and Federal Elements Matrix" A

The team will provide the posting model as a resource once that has been defined. Typically we see the accountants creating t
with the appropriate accounting entries for the debits and credits. Through the analysis of the manual SLTs and integration po
the BAS team will review the business requirements for manual journal entries. In BAS, the subledger accounting practices and
process flows should reduce the direct entries required in the GL module.

BAS is currently building out the crosswalk and will have a dedicated session on 3/31/2021 to walk through this.

The Oracle EBS functionality of Project Code is synonymous with what we are calling Project Number. For projects created in O
EBS, each of them will have an associated Project Number.
The team is currently analyzing the ACS values to determine an approach for PPA reporting. This approach will be shared with
bureaus in Sprint 2 for feedback/discussion.

Due to g-invoicing patches, the topic of reimbursable projects will continue in Sprints 2 and 3. These Oracle updates will chang
look and feel of the interface. We are waiting until the first patch is successfully integrated in our current test environment.

For Direct Projects, this will be more aligned to what you saw on 12/8 for Indirect Project/Task creation. We will be revisiting t
topic for the OCM team in a video walkthrough in January 2021.

In terms of templates, this is going to be something we will need to continue to conduct needs analysis on the various fields fo
reporting needed on that Project Header Template. There are distinct categories (i.e., Capital, Reimbursable, Indirect, etc.) of
Projects, but you can have many different types of templates. There will be more to come on this topic in early 2021.

Indirect Projects is an Oracle Terminology which should correspond to the Direct Projects at DOC.
These Projects are intended to collect costs only generating any billing or any capitalization.
This said, it might be that some Direct Projects (in any Bureaus) do generate billing and revenue, if this is the case then we will
to look at that in more detail (and please confirm if that scenario exist).
We will talk about these projects as part of the Cost Allocation.

CWIP projects are being reviewed and assessed by the Sunflower Team in conjunction with the Oracle EBS Projects. We are lo
into that in order to envision the capitalization flow within BAS application to Sunflower. We will identify the questions require
fully assess the CWIP business requirements throughout Sprint 2 - 4.
BAS will be detailing conversion in greater detail in FY 22.

BAS is currently building out the crosswalk and will have a dedicated session on 3/31/2021 to walkthrough this.

There are ACS mappings on the Project and the Task. These two levels differ. For example, for BFY, we have linked that to the
"Task". So, if you have Project-X and that Project has 10 tasks, you can assign each Task (i.e., 1, 2, 3… 10) with different BFY's, F
Program, and Org.
Project is the top of the hierarchy and is linked to an organization, members, and POP dates while Task is the sublevel and is
associated with the ACS values and POP dates. Different Project Types (i.e. Reimbursable) impose additional business rules at
task level such as linkage to a Reimbursable Agreement and artifacts related to the customers obligation information.

BAS is currently building out the crosswalk and will have a dedicated session on 3/31/2021 to walkthrough this.

BAS will be walking through Projects Reporting in Sprint 3.

The Direct Project Type will follow a process flow. During the CVS checklist, foundationally, that is what the process will look fo
Direct Project Types. The equivalent Oracle nomenclature is "Indirect Project Type".

BAS will be walking through ACS mapping in greater detail in Sprint 2. We presented the ACS mapping in our Project Basics ses
on 12/8.

At the Project level, we are capturing Bureau and Org. At the Task level, we are capturing Fund, BFY, Program, and Org. Please
to the materials from the 12/8 presentation. We will also be revisiting this topic in the PTR session on 3/31/2021.

There are distinct categories of projects. Oracle EBS Indirect Projects are similar to the CBS version of Direct Projects. We are h
conversations about Oracle EBS - Projects functionality and how (if) Sunflower will be supporting this capitalization endeavor.
plans to conduct a video walkthrough of Capitalized Projects for the OCM team. This is slated for Sprint 2.

The start and end date rules are as follows:

Start Date: Can be changed, but typically this is not done if there has been activity. Associated tasks need to be set within the
parameters as well.
End Date: It can be extended with the following limitations, it cannot be pushed backwards if there is activity past the new en
Further, it can be extended into the future as long as it does not go beyond the availability of the funds.

When we refer to Indirect Projects, we are speaking about those projects that are related to collection and allocation of costs.

We are having current decision discussions around this topic. More information will be presented in Sprint 2.

Project has a start and end date. Similarly, tasks have a start and end date. These dates can control set the parameters for wh
project must conclude. At each task, there is a setting to indicate whether it is chargeable or billable. For RA projects, the billa
check box will be enabled. If a project is categorized as "Capital" or "Indirect", they can only accumulate tasks.

The start and end date rules are as follows:

Start Date: Can be changed, but typically this is not done if there has been activity. Associated tasks need to be set within the
parameters as well.
End Date: It can be extended with the following limitations, it cannot be pushed backwards if there is activity past the new en
Further, it can be extended into the future as long as it does not go beyond the availability of the funds.
We do not know what the final verdict will be on the Project Number recommendation today. We are still having conversation
about this.

In terms of your questions for creating a new project each year, that is entirely up to you. There are two recommendations for
scenario. You can leave the "END DATE" field blank and you do not need to create a new project, but you can revise it. The sec
option is you can fill in the "END DATE" for that 30-month lifecycle and create a Project Template. Therefore, Oracle will auto-
MAJORITY of those fields for you and you would need to double check the information to ensure it's accurate and up-to-date.

This is a topic that is currently undergoing internal discussions. We have not arrived at a formal recommendation yet. Howeve
numbering in Oracle would change the "FY" prefix at the start of the FY and the series of numbers behind FY would be auto-
sequenced (i.e., 21000001, 21000002, 21000003, 21000004).

Thank you for your feedback. This is something we will take back to BAS PMO. However, we have not arrived at an official
recommendation of Project Number.

Yes, this will be a decision made across the entire department (including the Bureaus). However, we are still discussing the fin
recommendation for the BAS solution and we have not come to a final decision.

Yes, currently in Oracle EBS - you can use the Project Description text field to add in notes associated with the Project or Task.

No, it is not necessary to create a task code for each charging organization.

CBS has a one to one relationship with Fund/Project-task. EBS does not have this limitation. A project can have tasks associat
with different funds.
When you say 8-digit Project Code, we are assuming you are talking about the Project Number. Is this correct? If so, this was ju
demonstration for the session. We will be working with the department to determination the codification of this Project Numb
There are no formal decisions made on this piece of information.

CBS has a one to one relationship with Fund/Project-task. EBS does not have the same relationship. While the Project is creat
associated with an owning Organization, it may have tasks that pull in funds/authorization from multiple funding sources.

The Project Header and Task Header forms have a mixture of editable, mandatory, and optional fields. There are some fields t
users cannot edit. In terms of Project number, we have not arrived to a formal recommendation on this. However, this would
field that Oracle should restrict users from editing.
System roles/permissions is a complex question across many different work streams. There will be functions that are held at d
levels of the Department and the Bureaus. Future conversations will flush out which roles are centralized and which are contro
the bureau level.

Yes, the burden schedule can be setup for a specific organization within the bureau.

The session on 12/15 was a foundational overview of the cost allocation processes in Oracle EBS, future conversations will exp
this foundation. Further bureau specific sessions in January will include a conversation of your existing cost allocation setup to
demonstrate how it can be performed using the EBS Cost Allocation Burden Schedules.
Rates are entered into the burden schedule and are applied based on the rules established

Yes. Rates can be set for an entire year and/or adjusted as needed during the year using the date ranges on the burden schedu

The system allows flexibility to accumulate overheads based on various factors. Each bureau will have an opportunity to work
the implementation team to share their current methodologies so they can see how those can be applied in an EBS solution. T
conversations will be scheduled early in Sprint 2.

We will be walking through Reporting and Analysis in Sprint 3. However, we will be conducting Cost Allocation meetings with e
Bureau starting in January. Our team recommends that you provide more information on what is needed. There is flexibility in
of adjusting the period of time you are looking at.

Yes, the cost allocation tools offer flexibility to charge overhead based on each bureaus business rules. There will be bureau se
in January to dig deeper into your current cost allocation setup and how it translates to EBS.

The burdens are applied in the order listed on the burden schedule.

Yes the system allows for an individual to define the order to apply the multiplier.
Five multipliers was just an example to show multiple levels can be applied but additional multipliers can be used.
The system allows to adjust the priority of the multipliers in order to perform the correct calculation

The burden schedule is linked to an organization so in your example each unique scenario would have it's own burden schedu
would be applied as necessary.

Burden schedules can be updated or added during the year.

When examining each bureaus current cost allocation methodologies in the January bureau sessions, a discussion of Over/Und
how it can be applied in EBS will be included.

The Type Firm is used when the Burden Multipliers do not need to be changed or updated whereas the Type Provisional allow
changes and updates of the Burden Multipliers in the Burden Schedule

Correct, electronic invoice submission is slated for Sprint 3 during the Vendor Portal sessions.
Yes, data validation will occur within the EBS system. Sprint 1 discussed the to-be AP Invoice validation business process.

It is our understanding that PM003 provides point in time approval validation. If any error occurs, the system stops the transa
and returns the error to the end user. In the to-be business process, the user will create the invoice and match it to the PO. Th
business process requires the user to validate the invoice before invoice approval routing. The invoice validation will generate
error messages or holds based on the data input into the system.

Entry of invoice data is only manual for certain fields (i.e. Invoice number, invoice date, and invoice amount) based on specific
scenarios. The to-be roles and responsibilities will be discussed in Sprint 2. As part of the to-be procedures, there could be inte
data for the AP Invoices which would not require any manual entry.

It is a standard functionality in Oracle EBS to validate inputs on a per-field basis. There are built in validation rules that issue
messages/warnings when the rules are violated, such as missing required fields, or incorrect date or number formats. For AP i
validation, the system will check financial details such as matched amounts, distribution variances. The AP Invoice holds were
originally introduced during Sprint 1. The AP Invoice holds will be reviewed again on 12/14/2020 as part of the Configuration
Validation Session (CVS).
The invoice types included in EBS are:
Standard invoice
Credit Memo
Debit Memo
Mixed Invoice
Recurring Invoice
Expense Invoice
Withholding tax
Pre-Payment Invoice
Interest Invoice

Receipts will be entered as required for the appropriate purchase orders.

For a No-Match invoice, the invoice #, invoice date, and invoice amount are entered into the Invoice workbench. For this invo
accounting entry will be created so that the accounting string is associated with the invoice, which will also initiate the funds c
When the funds check is approved, the invoice will go through validation and approval for payment submission. If the funds c
rejected, the accounting will need to be reviewed, corrected, and then resubmitted for funds check.

Oracle Payments will be discussed during Sprint 2. In terms of the access to see different obligation data, the roles and
responsibilities will review the access (inquiry only, data entry, etc.). An inquiry role, view only, would allow users to review
purchasing data related to the obligation.

Create Accounting is a standard Oracle process that creates the corresponding accounting entries based on the transaction
accounting events. Based on the accounting conditions, the subledger accounting method will derive the accounting string (de
credit pairs) based on the defined posting model. During the invoice creation process, the create accounting step will generate
accounting string to support the invoice activity.

Oracle Payments and Travel interface will be discussed during Sprint 2.

The corrections button is not currently part of our recommendation for the standard invoicing process. This functionality is re
to credit memos where the system drives the correct credit memo amount via clicking on the button.

Integration will be covered later on in Sprint 3.

Oracle Payments will be discussed during Sprint 2.

Oracle Payments will be discussed during Sprint 2.

The IPAC discussion will take place in Sprint 3.

Correct, the process flow is a high level view. This will be walked through (on the EBS side) during the CVS for AP Invoicing on
After the Common Solution, the detailed business process would be documented which would support the eventual user acce
testing. This process flow would also include the hand off between different roles including the AP invoice entry vs. approvers
To comply with the prompt pay act, Oracle EBS provides the following capabilities:
Due Date Calculation, Economically Beneficial Discount, Reason Code processes.
Oracle Payables module calculates valid interest penalties on late payments automatically from funds budgeted and allocated
program for which the late payment occurred.

Oracle Payments will be discussed during Sprint 2.

Yes, we can define a supplier as federally reportable by enabling the Federal in the Supplier setup.

The system uses the Due Date Calculation, Economically Beneficial Discount, Reason Code processes.

Oracle will support workflow related to the defined roles. AP Invoice Approval roles were discussed during Sprint 1 AP Invoice
discussion. There was a data call to bureaus to understand required approval levels. We are reviewing current DOC business
processes, and will provide a recommendation in Sprint 2.
Based on the business rules, we recommend that the approval levels be limited to 3. For example, the supervisor of the individ
who entered the invoice, the COR, the buyer. Based on the provided approval levels, we will highlight the way that Oracle pro
controls for AP Invoice entry that will simplify and standardize the AP invoice process.
Do you mean for obligation (PO) or invoice? There is no approval process for receipt entry. For contract awards, the PRISM
discussions will review this in Sprint 2. For AP Invoice entry, this is currently being worked as an item from Sprint 1 discussions
There will be a standard approval workflow for AP Invoice entry.
It is our understanding that CD435 is a Procurement Request which is the first step in the procurement process for purchases
purchase order, delivery order, and contract. These documents are prepared on the basis of the Form CD-435. Finance payme
made based upon the procurement document. In order for an accountable piece of property to match a payment record, the
CD-435 must be prepared according to the provisions of this Order. If this is the case, then the requisition would be created in
with the corresponding contract award also created from the PRISM requisition.

The IPAC discussion will take place in Sprint 3.

EBS will inherit the attributes and structure from PRISM for the UOM (whether that is quantity based vs. USD based). There wi
be rounding issues based on the business process in how the user should match. This will be explained as part of the to-be pro
during UAT and training.

Prompt Pay will be calculated based on the invoice date. After the invoice is approved, the Due Date calculation can be initiat
before the invoice is submitted for payment. The calculation compares the terms date with the goods/services received date.

Yes, there are descriptions for every line of acctg. in Oracle EBS.

Please confirm the business scenario where you would have one invoice with multiple POs referenced. Does DOC receive an in
from one vendor with multiple POs?

The recommendation for tolerances will be shared during Sprint 2.

The recommendation for receipts will be discussed in Sprint 3. Roles and responsibilities will be reviewed during Sprint 2.
The recommendation for tolerances will be shared during Sprint 2.
The Payables module has the standard functionality of creating invoices to pay off interest for overdue invoices.

Payables automatically schedules payment for each invoice based on the Payment Terms and Terms Date you enter for the in
Payables uses the Payment Terms definition to calculate the due date, discount date, and discount amount for each scheduled
payment. For example, if an invoice has Payment Terms of Net 30, Payables calculates the due date as 30 days after the Terms
You can assign default Payment Terms to a supplier.

Travel interfaces will be covered during Sprint 3.

We will walk through the details during the AP Invoicing Configuration Validation Session on 12/14.

Depending on the status of the AP Invoice, there will be defined business processes for the adjustment entries. Oracle suppor
capability where users can make adjustments to invoice details, distributions, and scheduled payments, even if the invoice has
posted to your general ledger or paid. The system allows you to reverse matched distributions and/or create new distributions
matching to new purchase order shipments or distributions of the same purchase order. If you add or reverse invoice distributi
you must also change the scheduled payment amounts to match the new invoice total, or Payables will place holds on the invo
during Approval. There will be a downstream process should you only need to adjust the AP Invoice information if the Paymen
details do not change (clearing invoice). You can use a clearing payment method to account for changes in the accounting
information / adjustment if you do not actually require funds disbursement. This is to be discussed during the session on 1/11
Sprint 2.

Oracle EBS system offers standard budgetary controls across the procure to pay life cycle and business flows - from commitme
through obligations and receipts, invoices(deobligations) and payments and the treasury confirmation. Obligations will origina
the acquisition system, PRISM. The deobligation activity will originate in PRISM and will pass financial edits before it is interfac
Oracle (financial system of record). It will confirm different financial edits (confirming the amount billed, etc.) before the deob
is processed.
Each responsibility will have identified reports that can be run ad hoc directly from the system. As part of Common Solution, th
standard reports process and recommended reports will be highlighted. The EDW workstream will review the data warehouse
mart strategy. Accounts Payable features such reports as:
- Use the Suppliers Report to review detailed information you entered for a supplier in the Suppliers and Supplier Sites window
report also shows if a supplier is on PO Hold.
- Submit the 1099 Payments Report to create a listing of payments made to 1099 suppliers. Submit the 1099 Payments Report
each tax reporting entity in your organization.
- Use the 1099 Supplier Exceptions Report to review 1099 suppliers with inaccurate or outdated 1099 income tax information.
1099 supplier is a supplier that you have defined as Federally Reportable in the Suppliers window. You should run the 1099 Su
Exceptions Report before you submit your 1099 reports to identify suppliers that Payables will treat as exceptions in your 1099
reports. You can correct these supplier exceptions in the Suppliers window. You should submit the 1099 Supplier Exceptions R
for each of your tax reporting entities.
- Use the Invoice Aging Report to analyze the cash flow of your unpaid invoices. This report provides information about invoice
payments due within four time periods you specify in the Aging Periods window.
- Use the Invoice on Hold Report to review detailed information about invoices on hold. You can submit the Approval process
submitting this report to obtain the most up-to-date hold information. To obtain additional detail for invoices on matching hol
can submit the Matching Hold Detail Report.
- Use the Invoice Register to review detailed information about invoices including only those that are cancelled or not approve
-Use the Invoice Approval Report to review the total number of matching and variance holds that Payables applies and release
you submit Approval. If you use budgetary control, Payables also lists any funds control holds.
- Use the Accounts Payable Trial Balance Report to verify that total accounts payable liabilities in Payables equal those in the g
ledger. Before closing a period, you can compare the cumulative total liability provided by this report with the total liability pr
by your general ledger to reconcile these balances.

All invoices (regardless of the matching) will require system validation against the obligation for accuracy before going through
approval.

The person entering the invoice will be responsible for validating the invoice. After validation, the invoice is then routed for
approval. The person who entered the invoice is not the person (or persons) who will approve the invoice. The system has
automated workflow that will notify those required approval personnel via email as well as a notification that will be in their w
(this notification will be viewable directly as they login).

Based on the Oracle configured workflow rules, the system will automatically inform the next person in the approval queue of
required action. The workflow will generate the required notifications both to the individual's work list as well as their email
(associated to their user account). The queue of approval requirements can be seen at the document level (either through the
forms or drilled down in the notification). Both views will show who the document is currently assigned to for approval and th
status, approval date. This feature was reviewed during Sprint 1 and will be highlighted again on 12/14/2020. Oracle Payment
be discussed during Sprint 2.

We are currently preparing the recommendation for the approval hierarchy, but yes, we are looking at 2-3 tiers for approval. T
roles identified (buyer, COR, etc.) are part of the assessment.

The validation process was reviewed as part of the AP Deep Dive. The 12/14/2020 session will review this again as part of the
related to the validation process. The Validation process is required before submitting for approval. The validation and approv
process for AP Invoices will be handled on the Oracle EBS side. The recommendation for approvals is anticipated for Sprint 2.
process will be an automated one.
Seeded holds are just the out-of-the-box reason codes to place a hold on an invoice. No configurations are required to utilize
invoice hold reason codes. The invoice hold reasons were introduced during November 2020 and will be revisited in the 12/14
session.
Oracle Payments will be discussed during Sprint 2.
The standard business process requires that any new funding action be processed via a requisition to add that funding to a con
award. If the scenarios is that an invoice / payment is processed (which would have decreased the unbilled balance) and that
payment needs to be reversed, the invoice cancelled, etc. Oracle will support the resulting action if that downstream activity i
reversed. If the AP invoice matching is reversed, cancelled, then the system automatically makes that funding available on the
obligation and can be billed later.

Standard OOTB capabilities for reporting and trial balance information will be real time. The transfer process (from subledger
will be on a set schedule by the O&M processes. There is also a feature where the user can push to the GL as well directly. The
standard reports are real time.
Accounting can be scheduled to run periodically as necessary to transfer and post documents to GL. This will be part of the O&
SOPs and defined batch programs.

Validated and approved invoices are processed through a payment process request, which is a standard disbursement proces
Oracle EBS. Sprint 2 will provide the detailed review of the disbursement process. We will discuss the process after the AP Invo
entered and how the payment will be processed and resulting accounting entries for disbursement and Treasury confirmation

There is no time limit for invoices to stay in the system. The recommendation for the document attachments will be to only att
the supporting AP Invoice to the record. EBS is not intended to be the file repository system. The file limitation is a non-functio
requirement that will be established as part of the technical architecture team. There will be a size limit established for EBS. T
be answered as part of their Common Solution review.

Documents will not be removed by any system SOP. If documents need to be flagged for "legislative hold" - this can be configu
an attribute for the AP invoice. Documents can be flagged for "legislative holds" by using the descriptive flex fields in the Orac
system. Please bring up legislative holds during the 12/14/2020 discussion so we can assess the business impact if this needs t
be a configured hold as part of the validation process.
We need to understand the requirements for the documents storage capacity per invoice. EBS is not meant to act as a
documentation repository for the bureaus. It should not replace a share point or shared drive as it is not a file share system.

There is no requirement for invoice attachments.

There is a standard Invoice Tolerances table where we will define tolerances DOC needs to allow for variances between invoic
purchase order, receipt, etc. We can define both percentage-based and amount-based tolerances.
We are having internal discussions to determine the flow for partial payments. The recommendation will be discussed during
2/3.
This feature is called Data Access sets. The PTR workstream has featured the data access controls as part of their Sprint 1 sess
On 12/10/2020, the data access controls will be reviewed. The Data Access controls support data restriction so that a bureau c
only see their own data, but not others.

Sprint 2 will feature the discussions related to integrated data.

Bank account information is setup and maintained per supplier pay site in Oracle EBS. It will be based on the supplier and sup
site selected during the invoice creation. The supplier site can have specific banking information assigned to that vendor supp
site.

Yes, Oracle EBS supports the capability of multiple lines of accounting.

Oracle Payments will be discussed during Sprint 2.
Prompt Pay will be calculated based on the invoice date. After the invoice is approved, the Due Date calculation can be initiate
before the invoice is submitted for payment. The calculation compares the terms date with the goods/services received date.

Multiple Distribution Lines can be entered in EBS.

We are confirming whether the lines tab in EBS captures the same information as a CLIN in CBS.
The project and task details are defined in EBS, and then are associated with the requisitions and POs in PRISM.

Multiple Distribution Lines can be entered in EBS

No.

Yes. The invoice number will be unique. The Invoice number will be specific to the supplier site.

Ex: Invoice number + supplier site.

INV#123 +SupplierSiteA and INV#123+SupplierSiteB

Yes. Funds check is done as part of invoice validation. If there are insufficient funds, the system will place the invoice on hold.

Yes. A manual hold can be applied to prevent the invoice from being paid before the acceptance date has passed.

Matching basis is on quantity.

We need additional context. Can you please give us the business scenario(s) that would require overwrite?
We would need to understand what is meant by vendor file and matching, and how it is currently done in CBS. There will be a
process to sync vendors between SAM and EBS, which will be discussed during the integration and Vendor portal discussion la
Sprint 3.

There is a field at the supplier site level to identify which address to use for 1099 forms.

Recurring payments functionality is available in EBS. Could you provide more details on sub invoice numbering concept?

Those individuals specified by the bureau who are responsible for committing funds would be able to access these details com
from PRISM to EBS.
There will be a process to sync vendor information between SAM and EBS. We have taken a note to ensure that the CAGE cod
captured. This will be discussed during the integration and Vendor portal discussion later in Sprint 3.

Yes, additional fields can be configured at the header level. We will discuss more on Prompt Pay during the upcoming session.

As we described in the session, we are still currently looking at the workflow. During the session on 12/14/20 we gathered mo
information on NOAAs process in which we will incorporate.
We have received the line office's input via data call in which we will incorporate into our next integration of updates.

Prompt Pay will be calculated based on the invoice date. After the invoice is approved, the Due Date calculation can be initiate
before the invoice is submitted for payment. The calculation compares the terms date with the goods/services received date.

We are still currently looking at the workflow. During the session on 12/14/20 we gathered more information on NOAAs proce
which we will incorporate.

We plan to discuss this in Sprint 2

We are still currently looking at the workflow. During the session on 12/14/20 we gathered more information on NOAAs proce
which we will incorporate.

Yes. We plan to discuss this in Sprint 2.

We will review roles and responsibilities for PO, AP, Payments, Project Costing at the PTP session scheduled for 1/29/21.

We are still currently looking at the workflow. During the session on 12/14/20 we gathered more information on NOAAs proce
which we will incorporate.

We plan to discuss this in Sprint 2.

Yes, We plan to discuss this in Sprint 2.

For a manual invoice, the invoice #, invoice date, and invoice amount are entered into the Invoice workbench. For this invoice
accounting entry will be created at the invoice level, so that the accounting string is associated with the invoice, which will also
initiate the funds check. When the funds check is approved, the invoice will go through validation and approval for payment
submission. If the funds check is rejected, the accounting will need to be reviewed, corrected, and then resubmitted for funds
The accounting information is inherited from the obligation/PO.

Data calls have been issued to each bureau and we are currently grouping the tolerances to be able to configure them accurat
We plan to provide recommendations in Sprint 2.

We are still in the process of reviewing the business process details for routing the approvals. Can NOAA please explain why is
CO getting all this information?

We plan to discuss this in Sprint 2.

A walkthrough of the invoice batching and routing for approval was completed during the AP Invoice configuration validation
session.

Invoices of similar origin (i.e. vendor) can be entered into the Payables module as a batch for processing. Depending on the ty
invoice and what type of matching (2-way or 3-way) was indicated on the obligation, the invoices will then need to go through
approval once validation is complete.

The received date is the receipt creation date for goods/services.

It's a pop up message in which you can click on the message to view the report.
We recommended that the user will run a draft manually and the system will generate accounting automatically.
We recommended adding the documents related to those invoices. The file size limitation will be confirmed by the tech team
the end of the Common Solution.

Validation must be performed on all invoices. Upon performing create accounting function, accounting entries are created.

We plan to discuss this in Sprint 2.

The VISIO is a high-level view of each process. We will review roles and responsibilities for PO, AP, Payments, Project Costing i
Sprint 2.

The accounting for manual invoices will need to be entered manually.

During the system walkthrough in the session we've shown many applicable date fields. We also plan to discuss this in the fut
sprints.

Configuration Validation Session (CVS) - opportunity for the Decision Making Forum (DMF) to review and approve the propose
business processes.

The invoice numbers must be unique. Payables will prevent the user from entering an invoice with exactly the same invoice nu
for the same supplier.

Yes. Invoices can be batched or entered individually.

This is by the Supplier not the object class.
Yes. One project can have multiple task and is used to generate the ACS.

Yes, PRISM will replace C-Suite as the system of record for obligations.

It will be the actual location where the goods were received. We plan on discussing the receipt process during Sprint 3.

The recommendation for receipts will be discussed in Sprint 3.

The AP Technician would know whether an invoice is 2-way or 3-way based on the obligation/PO information that is adopted
the invoice.

If by "more than one type" indicates more than one type of invoice associated to a PO, then, Yes that is possible to have a mat
invoice and a no-match invoice against the PO. The obligation must indicate these different types.

Discounts can be entered in the Payables module with the Payment terms.

Both project and task numbers are created in the EBS Projects module.

However, both project and task information is visible in the Payables module when the obligation information is adopted into
invoice creation view.

The accounting lines in each CLIN would be reflected at the distribution level (Distribution tab) in the workbench.

As we continue to gather bureau details for business scenarios, we are also working to compile this information to formulate a
standard recommendation for all business processes for BAS.

We would need additional clarity to address. However, if this question is related to user roles, we plan to flush this out in Sprin
during the RBAC discussions.

Yes. The system will give details on the funds check failure.

Additional distribution lines can be added as necessary.

Generally, the validation is not performed on the text box fields. Which text box is being referred to here?

This question was addressed during the configuration validation session as an example.

The paperclip icon will show a paper attached within the icon when an attachment is present on a document.
It is our recommendation that no PII/BII is included on any documents entered or attached to a document in the system.

Yes. This system shall have the capability. As discussed in the session, we will need to understand the business process from th
bureaus.
If "locked down" means that the attachment won't get erased from a record, then yes, attachments will not be removed from
record if applied.

If the line of accounting is not posted yet, the entry can be deleted. However, this will be discussed further during the Plan to
Journal reversal session on 3/1/21.

There will be an interfaced payment indicator that will go back to PRISM. The AP Payments session will be held on 1/26/21.

No. Not every invoice in a batch needs to be approved to submit for payment. EBS allows criteria to be selected for a payment
that indicates which invoices will be submitted for payment.

We have reached out to each bureau for details on their approval hierarchy and are finalizing our recommendation.

Preliminarily, our recommendation will be to have 2-3 approval levels for invoices as part of the BAS solution. Due to automat
system checks and validations that occur in EBS, it might not be completely necessary to have more than 2-3 levels of approva
invoice.

We have reached out to each bureau for details on their approval hierarchy and are finalizing our recommendation.

Preliminarily, our recommendation will be to have 2-3 approval levels for invoices as part of the BAS solution. Due to automat
system checks and validations that occur in EBS, it might not be completely necessary to have more than 2-3 levels of approva
invoice.

During a data call on 12/21, BAS requested that NOAA provide their current workflow and an example of a training document
CD435 was sent in for review. Training documents will be taken into account for the recommendation.

We are working closely with the EDW team to avoid duplicate efforts. By doing so, we will work internally before sending any
request to the bureaus - as we do not want anyone to do the same work twice.
Regarding the Summary Tab, the goal is for bureaus to give us the report name and logic, which is going to help us analyze if w
both using the same terminology to describe the same outcome, or maybe it is different terminology but the same outcome. A
you'll see in the Core Apps Standard Report data call - there are instructions to address if you believe you have already provide
report.

Project code is not a standard parameter for AR reporting. This is something we will need to have a further discussion on. The
reports in the Oracle Projects module that may suit your need. If it does not, the BAS Team will perform analysis to determine
to best meet the reporting need.

EDW Power users may be able to build reports that meets their need and are exportable in Excel.
Yes, however, we need to do an official hand-off to get those data requirements. Once the Core Apps Standard Reports requir
are established, EDW has a path forward to ensure they capture the appropriate reports, data elements, and underlying DB ta
meet this need.

Yes, reporting across different fiscal years will be available. Depending on the report, different reporting parameters will allow
bring in specific date ranges (Year-to-date, etc.). Agreement, project and task structure is evolving. The project agreement has
amount which can be increased /adjusted based on the year(s). The projects module will track billing against the agreement a
There are options available in project agreements to put a hard stop on billing and revenue which will ensure that the billed am
does not exceed the agreement amount. There are number of project billing reports as well as project billing inquiry which giv
snapshot of agreement amount versus billed amount and amount available for billing. Open document conversion plan will b
discussed in later sprints. In general, the concept that open and active transactions will be part of the conversion plan.

Though there are 160 standard AR reports, you will find that on the attached slide we have previously discussed the roadmap
reporting. BAS Core Apps has provided the Top 10 AR Reports along with a Month-End Playbook. The BAS PMO has also provid
reporting deliverables which will well frame the reporting strategy. Please refer to the Reporting and Analysis session deck hel
11 MAR for more guidance and information.

Yes, they can be bureau specific. Additionally, this feature can be user defined. For example, a user can go into the system and
decide which cadence and frequency they would like Oracle to run specific reports. In addition the reports can be run by users
time based on the need (or ad hoc).

Yes, it is a conceptual process that is applicable to both YE and ME close processes. We have gathered information and feedba
across the department when we put together our playbook. We had multiple data calls soliciting representatives from each bu
to share the common reports they use daily. The to-be month end close / year end close processes will be reviewed as part of
future sessions and included as part of the cutover plan for future deployment phases.

Yes, reports can be run individually at scheduled time or on demand or as set of reports in report set also. Various types/class
reports can be made into a report set and run the report set. Each report runs in its own thread and the system will have a
predefined number of concurrent managers to run the reports. There is an Internal manager which monitors all the concurren
requests and queues and routes the reports to available managers . This is all done by the system automatically and user
intervention is not required. Optionally the system can be configured to send an email notification upon completion/failure o
request. This will be discussed in later sprints when the system configuration and testing are at an advanced stage.

Yes, end users will receive training on how to navigate reports. In addition to training, Oracle provides user manuals for guidan
assistance. The help section orients users to the various features on the screen and helps users troubleshoot common errors.

Currently, they are not available in the Standard AR reports. Core Apps has flagged these reportable fields and will collaborate
EDW to ensure this feedback is captured.

You can refer to the Receipts and Collections deck from 11 MAR for more information on this topic. On a receipt, there is a fie
"creation method". AR reports can be used to capture how many receipts have a creation method of "Bills Receivable". Is ther
specific business case/need you are thinking of that would be needed re: bills receivable? Please advise.

SISP is an interfaced program. We will discuss this topic in the future during the system interface sessions.
A wash account in this context is when the system is creating accounting for unidentified receipts, and it puts in a specific acco
Later, when you associate it with a specific customer, it is no longer an unidentified account; basically, we know the customer
have the accounting specified. Wash account generically can be synonymous with clearing account. As part of future training e
we will provide the terminologies we would expect to be used in the to-be business processes.

Entering a receipt first without the verified deposit information is an optional process. NOAA can always first send the checks
clearance and then create the receipts. The flow chart presented in slide 9 is only for information purposes. However, this pro
needs to fit under the One Solution concept.

Oracle will enforce separation of duties by the responsibilities which will allow users to access the only functions they require
their job role. In addition to that, the bureaus will have segregated data through data access controls.
We have a dedicated session on this topic in Sprint 3. The calendar is currently being finalized and we do not have a solidified
In the meantime, NIST has provided a demo on this process on 3/23/21, which will help us get a better understanding the
configuration requirements.

ODI capabilities were not identified as part of the BAS to-be requirements.

This topic will be covered as part of Sprint 3.

We will have a discussion on the deposit ticket at a later session. Standards remittance is when the checks are sent to the ban
clearance (OTCnet), and no-remittance is when the bank already cleared the receipts (checks, credit cards, ACH, Fedwire) and
funds are remitted to the bureaus via the Collection Information Repository (CIR) report

Any return of unused customer receipts as well as AP and AR netting are possible without any programming or modification. If
customer has AP invoices as well as AR invoices you cannot drill down from one to the other. However the system can do the
netting process.

We will discuss the features of AP / AR Netting in Sprint 3.

The BAS PMO team is currently working on determining the appropriate Original/Supplemental Appropriation attribute forma
structure update will be part of Sprint 3 items for ACS as we work on finalizing structures of each segment for the BAS ACS. A n
version of Fund crosswalk between latest CBS Fund Codes and BAS Fund Codes will be shared with Bureaus once we have dec

The BAS PMO team is currently reviewing this scenario. This structure update will be part of Sprint 3 items for ACS as we work
finalizing structures of each segment for the BAS ACS. We will share the solution design for this scenario once we have a decis
As shown in system walkthrough during the 3/25 session, allotments can be created at higher level within Program segment s
at DOC Sub Activity Level which is BAS ACS Program Level 4. This will allow spending at lower levels such as Level 7/8, which ar
Internal Code and Internal Sub Code levels. The recommendation is to standardize apportionment at a particular level across t
department such as at DOC Sub Activity Level.

Tolerances for budgetary funds control is a different type of tolerance than tolerances relating to no match invoicing transacti
Budgetary tolerances are setup to override funds control for a particular type of transactions (e.g. Payroll). These budgetary
tolerances need to be standard across all bureaus as this configuration is based on single ledger setup. For Invoice Tolerances,
PTP workstream is working with the BAS PMO to understand the requirements related to invoice tolerances as an outcome fro
Sprint 2.

No, the Reprogramming Transaction screen is a standard out of the box capability in EBS which allows transfer of funds betwe
account combination to another. (e.g. from one Program to another Program, from one ORG to another ORG or from one
Program/ORG to another Program/ORG)

Regarding the CR process, different budgetary transaction types can be setup to record:
1. Setting up the CR
2. Recording FBWTCR (1090)
3. Setting up Authority Temporarily Unavailable pursuant to Public Law - current year (4395)
4. Clear FBWTCR (1090) to 1010 and setup Unexpended Approp (3090 to 3101)

The Project/TASK and BAS ACS materials from 3/31 session gives insight on how Project and TASK from EBS Projects module a
linked to BAS ACS (reference the Account Generator and POET attributes). The accounting string is tied to the transactions tha
related to the Projects downstream transactions. For reimbursable activity, the billing events, etc. will be generated for the ind
transaction. There will be additional sessions to build on these concepts throughout Sprint 3.

The IPAC bulk file will not be generated from EBS/BAS. The former bulk file interface was only intended to support buy/sell
transactions, which will be handled by G-Invoicing going forward.
For inflight orders that are not initially transitioned to G-Invoicing, there will be an adapter in BAS that will work similar to APS
to load transactions to AP or AR. These can be used to load IPAC transactions for the interim period until all IGT/IAA Orders ar
Invoicing.

As of 10/1/22, all new IAA Orders will have billing and collections processed through G-Invoicing. This is intended to eliminate
of the existing IPAC matching issues.
For inflight orders that are not initially transitioned to G-Invoicing, there will be an adapter in BAS that will work similar to APS
to load transactions to AP or AR. These can be used to load IPAC transactions for the interim period until all IGT/IAA Orders ar
Invoicing.

The intent is that an IAA for GSA Rent will be setup in G-Invoicing starting on 10/1/2022. Full solution related to the details of
transactions in BAS is still TBD, as the patches to support GINV performance transactions have not yet been released.
1) All buy/sell collections and disbursements will interface to IPAC through G-Invoicing directly. EBS will only interface with G-
Invoicing, and the concept of a bulk file will no longer apply.
2) Non-buy/sell transactions (such as Treasury Collections for outstanding debt) will need to be entered manually into EBS, or
uploaded via BAS adapter that will work similar to APSI/ARSI to load transactions to AP and AR.
3) All IGT Buy/Sell activity will be part of the G-Invoicing Solution. This will include GT&C, Orders, Performance (Billing) and
Settlement (IPAC/Cash).

All buy/sell collections and disbursements will interface to IPAC through G-Invoicing directly. EBS will only interface with G-Inv

There is currently a plan to have an "adapter" or bulk transaction load capability, similar to APSI/ARSI process which could be u
load transactions to AP or AR, including IPACs for non-buy/sell activity, or for inflight IAA orders that aren't initially loaded to G
Invoicing.

Yes, all billing (performance) will flow through G-Invoicing. The invoice will be created in EBS as part of the G-Invoicing integra
For inflight IAA orders that are not initially loaded to G-Invoicing, there will be a bulk load capability in EBS similar to APSI.

Details related to the process for billing and collections will be discussed later in Sprints 3 and 4, as the Oracle solution is flush
Details of what transactions will or will not be included on the IPAC file is still TBD (e.g., whether G-Invoicing IPACs will be inclu
and, if so, how they will be identified).

Initiate Payment refers to any scenario where the payment is "pushed" by the agency disbursing funds, instead of the other ag
initiating the collection to "pull" the funds.
If the scenario is related to an IAA, then all activity will be processed through G-Invoicing. If it is other non-IAA (non-Buy/Sell)
activity, then we may need to understand the detailed process that occurs today in CBS.

Yes, this will go through G-Invoicing. Refunds are an upcoming topic for the IGT working group, to understand how these will
G-Invoicing, so more to come on this topic.

Need to understand this a little better - how is this recorded in CBS currently? If this is a collection that is processed by Treasu
the bureau's behalf, then the transaction would be recorded in EBS, possibly as a cash receipt.

Going forward, an IAA will be required for all investigations and GSA transactions, and all will be processed through G-Invoicin
Collections will be entered as AR Receipt in EBS. There will also be an "adapter" in BAS that will work similar to APSI/ARSI to lo
transactions to AP or AR. These can be used to load some of these other IPAC transactions

GT&C, Orders, Performance (Billing), and Settlement (IPAC funds transfer). A high-level overview of the transactions and how
will relate to EBS transactions was provided in CS sessions on 4/8 and 4/19. Additional sessions are scheduled for later in Sprin
and 4.

Sessions for the PTP (requesting agency) side of IAAs will be scheduled later in Sprints 3 and 4.

These transactions will be recorded in one of the EBS modules, depending on the type of transaction. For funds being receive
the bureau (collection), an AR Receipt will be entered in Receivables, and will post to the GL from there. For funds being paid
the bureau (disbursement), an AP Invoice/Payment will be entered in Payables, and will post to the GL from there.

The full solution for non-IAA (non-Buy/Sell) collections is still being flushed out, so the actual module(s) that will be used to su
this have not been finalized, and will be discussed later in Sprints 3 and 4.
The example is for receipts, reimbursables and deposits. As discussed during the session, we will need some data to test
reimbursables. We plan to coordinate with NOAA to schedule a demo of how reimbursables currently works in CBS.

In EBS, a customer receipt is applied to a reimbursable agreement at first. When receiving an advance for a reimbursable agre
wherever billing happens it will reduce the amount. If there is no advance it will not be applied to the reimbursable agreemen

As discussed during the session, we will need some data for reimbursables. We plan to coordinate with NOAA to schedule a de
how reimbursables currently works in CBS.

There will be different ACS segments on the task level. So, yes, you can enter different ACS segments there. The refund activity
receivable account attached to it and that is the account it will use in invoice creation. Each bureau can set up a receivable acc
( complete ACS string ) as per their requirement. The ACS string can be edited as needed, however there can be only one activ
string for a refund activity at any one point of time.

There is no other linking between AR and AP other than customer returns and AP/AR netting. In the example presented we ha
payment terms set to immediate and no approval required so then the invoice was created immediately and ready for payme
From there the AP payment process schedule which may be scheduled at daily/weekly etc. interval.

The Oracle system will alert the end user for fields that are missing. If the customer information is missing, the end user will no
the associated information as a "search option" in the system.

Yes, that is correct you will have to select a vendor number from the screen.

You can store customer bank information on the AR customer screen and then it will pull that information.

There are three separate remittance message lines available for the user to enter any text they would like to enter. Any of the
lines could be designated and used for the purpose. Reimbursable agreements are tracked in the Oracle Projects Billing modul
user wants to refer to them, they must pull the reimbursable agreement in the Oracle projects module based on project numb
then refer to them in the refund messages.
Standard AR receipts are applied to the Bills of customers. For reimbursable advances, the money is applied to the agreement
Project bills are interfaced to AR, the system looks up the agreement and receipts. Accordingly, the bill amount is reduced by t
advances received.

For reimbursables the project number appears on the transactions screen and some other project info will appear on lines. Th
how the bills can be distinguished between RA bills and non-RA bills. However, receipt /cash application process does not
differentiate between RA bills and non-RA bills and it will pull them up in a receipt application window if the customer has dire
as well as RA bills.

At this point of time IPAC process and G-Invoice process related to federal customers need to be configured and tested. More
scheduled related to this topic in Sprint 3. For non-federal reimbursable customers, the configurations related to project billin
needed for testing this functionality. The demo is primarily for AR refunds.

As discussed during the session, RBAC will support this data restriction. Each bureau will only be able to see their own refunds
example, any end user with the responsibility in Oracle will see all refunds within NOAA (even ones you did not initiate). For N
they will see the ones that are aligned to NIST and other servicing agencies such as ITA and OS.

As discussed during the session, once we have a demo with NOAA on reimbursables, we can discuss allotments related to refu
and how that works.

A user can use any of the Reference messages 1,2,3 to enter agreement info as required.

There is currently no designated field to refer to pull up the reimbursable agreement as the agreements are stored in project b

For AR refunds, CR cash is one side of accounting. During refund activity (ACS), account must be defined as part of the Receiva
activity definition and attached to the refund activity. We are applying the refund to a receivable activity instead of the invoice
triggers the AP invoice creation and closing the receipt based on the refund amount. Yes, you can do partial refunds.

We recommend that customer and supplier maintenance is managed by DOC.

During our customer session back in Sprint 1 on 10/13/20, we have discussed this. However, given the feedback from this sess
4/8/21), we are actively tracking this internally and plan to provide additional information at our next customer refunds sessio
slated for 6/4/21.

The pre-deployment process is referring to the timeframe before bureaus go live with the BAS solution.

The refund activities related to unapplied funds and is not related to the expiry of underlying agreement. However, the refund
process for reimbursable agreements will be tested when the Project Billing configurations are in place.

For check payments, no banking information is required. For electronic /EFT/ ACH refunds, the customer bill to address should
the banking information. Only for those customers who have banking information, will have the ability to receive funds
electronically. Otherwise, the system will force a check payment. Customer name is same as Trading partner name for vendor
payments. Optionally you have the ability to enter address information in payment attributes, which enables bureaus to mail i
correct address / any new address as required.

The credit/debit memo will affect the obligation balance by reducing the amount that the credit/debit memo indicates. Payab
updates the quantity billed for each of the originally matched purchase order shipments and their corresponding distributions
credit quantity you enter. Payables also updates the amount billed on the purchase order distributions.
For AP, both debit memo and credit memo posting are as follows:
DR USSGL 3107 (Obligation)
CR USSGL 4902 (Expenditure)

Since we are using 6-digit USSGL it may be as follows:

DR USSGL 310700 (Obligation)
CR USSGL 490200 (Expenditure Account)

Credit memo and debit memo use the same account. Debit memo is when BAS records a reduction in invoice due to certain
discrepancies /defects /returns. Credit memo is when the supplier sends a correction to the invoice. Accounting is same and b
works to reduce the invoice balance.

For AR transactions, the postings for credit and debit memos are the following:
Credit Memos:
DR Revenue
DR Freight (if you credit freight)
CR Receivables (Credit Memo)
DR Receivables (Credit Memo)
CR Receivables (Invoice)

Debit Memos:
DR Receivables
CR Revenue (if you enter line amounts)
CR Freight (if you charge freight)
DR Receivables
CR Late Charges

The use of a Credit Memo is when a negative amount invoice that is initiated by a supplier and sent to the Bureau to notify of
credit.

The use of a Debit Memo is when a negative amount invoice that is initiated by the Bureau and sent to a supplier to notify the
supplier of a credit you are recording.

Example: Returned items or Damaged Goods no longer required. Bureau would send Supplier A debit notifying of the damage
goods and requesting a credit memo from Supplier A.

Yes. An error will be returned if the amount is mistakenly entered as a positive amount on the header.

If the amount on the header does not match the total amount on the General tab, then the amount on the General tab is disp
in red and an error will be returned if you try to validate the transaction.

No, once an obligation/PO has been paid in full, bureau can no longer transact against the obligation/PO. At the most, a manu
adjustment can be performed, however, the status of the obligation/PO will remain closed. Yes, EBS does track the status of a

EBS will not automatically generate a credit/debit memo and send to the supplier. The bureau will have to initiate the credit/d
transaction and notify the appropriate parties accordingly.
The funds will remain. The bureau will have to initiate deobligation on the PRISM contract award to follow the recommended
business process. All acquisition actions should originate with the PRISM transaction.

If there are no other open invoices to apply to for that supplier, then yes, it will apply to the next invoice that comes in.
You can visit the CSC Portal BAS Page. Within the "Real Property Training and Deployment Documentation" column, you will b
to view specific job aids, training session recordings (available May 2021), and the official Sunflower Real Property  User Guide

The BRPCCB oversees configuration integrity and the addition of enhancements. You can learn more about the BRPCCB by nav
to the BAS Website. The document describes: BAS RP Governance Processes, BRPCCB scope, goals, and meeting frequencies, a
Service Level Agreements (SLAs) for RP Production Support, specifically the BAS RP Help Desk.

Submit your request via CARTS. Your request will be reviewed by the BAS RP Help Desk and presented to the BRPCCB. Your re
will require a business case. Upon approval, development, testing, and release schedules will be determined and the SDLC pro
will begin. Click here for more information about help desk and release management processes.

The BAS PMO has slated FRPP testing for Summer 2021. Further details and logistics will be communicated by the BAS PMO.

Yes! The BAS Real Property Training Team will update Training Documentation as new functionality is released or configuratio
changes are made. You will be informed of the change(s) and documentation will be available on the BAS Page of the CSC Por

The receipt date is captured in the system when creating a receipt in EBS. We are currently collaborating with our internal tea
confirm the logic in EBS. The slide included a Visio diagram that represents the business process flow and decision trees. This i
standard way to show how transactions flow through the system. This is not meant to capture every data element entered.

The PRISM document will require the user to select 2-, 3-, or 4-way match at transaction entry. This is required as part of the
recommended business process. This will be identified on the PRISM side before invoicing occurs. If an obligation/PO is interfa
EBS as 3-way, the invoice will be required to be 3-way matched. The matching option cannot be adjusted following the interfa
POs.

The PO revision number indicates the version that the obligating document has been updated to following a modification. The
revision change of the PO would be the result of the change order being processed, for example.

Yes. IPP has been selected as the DOC E-invoicing solution. IPP will interface to EBS and populate the required fields and scree
plan to discuss the IPP topic in a future sprint.

IPP to EBS configuration will be discussed in a future sprint.

The Receipt Date on the Receipt Header form is the date the goods or services were received on a 3-Way matching invoice typ
invoice received date is a separate required field located on the Header section of the Invoice Workbench form. The current P
pay calculation configuration will be based on the invoice received date in the AP module.

The term "Accounts" refers to the complete ACS string. When the intent is to refer to USSGL account it will be called out that w

During the session on 4/15/21, we learned the bureaus do not use the 3 items (Cash, Receipt Confirmation, Remittance). Since
are not going to use Oracle remittances, these items will not be used in the BAS solution. However, the process/accounting be
Oracle remittance is explained as follows. A receipt remittance batch goes through the remittance and confirmation steps. Firs
batch is created, and the batch can be modified until it is confirmed. Afterwards the batch is remitted either physically or
electronically. Oracle creates accounting at each stage of remittance batch process.
A remittance batch refers to a group of receipts that are to be cleared. However, since we are not going to use Oracle remittan
these items will not be used in the BAS solution.

This was discussed and demoed as part of the Sprint 1 session on 10/19/20, but there will be additional follow ups in Sprint 4.
However, to recap, if there is an advance against a reimbursable agreement, the receipt is first entered in Accounts Receivable
and then in the projects module the receipt is applied to the agreement. When the bill comes, it is interfaced to AR. The auto
process creates the bill, as well as reduces the bill due amount by the advance received (as a project, agreement, receipt, bill)
are interconnected. In cases of non-advance reimbursable agreements, bills and receipts are independently enterable and a re
can be applied to a bill when both pieces of information are available in the system.

We held a session and demo on receipt batches on 4/22, when we discussed this topic. We held a pay.gov session with NOAA
and plan to have a pay.gov session with NIST and Census within the next two weeks.

We held a session and demo on receipt batches on 4/22, at which we discussed this topic. We held a pay.gov session with NO
5/3 and plan to have a pay.gov session with NIST and Census within the next two weeks.

We discussed this process during the receipt batches session on 4/22. These will be entered as manual receipts; the Seafood
Inspection will be addressed via an interface discussion at later session.

If the bureau does not have a bill, it will be entered as miscellaneous receipt. Or if the bill is going to come later it will be enter
either an unidentified or unapplied receipt.

Yes, unidentified account has to be identified for each receipt method.

Receipt method is not only a name, but it has accounting associated with it. The cash account (USSGL) to which a receivable p
dictated by the receipt method. Based on the USSGL account to which a cash should be posted additional receipt methods wo
configured.

Correct. Receipt method could indicate a source of receipts and is also tied to accounting. Multiple receipt methods could pos
same USSGL account.

A bill may have one or more receivable items base on how the bill is created. When a receipt is applied the receivable ACS stri
from a bill is used and USSGL account is copied from receipt method. We plan to have a system walkthrough and demo for
accounting at the next receipt remittance session slated for 6/9.
As discussed during the session on 4/15/21, receipt entry and receipt application can be done by a single person or different p
based on how the work is organized. The system can be configured either way. The screens do not represent necessarily a sep
of duties. In Oracle, we rely on the responsibility to enforce separation of duties. The configuration will be done based on the
requirements received for the one-instance.

At the deposit ticket level there is no customer info. Only a receipt has customer info. This could be entered at receipt entry ti
later on updated if customer info is not available at the time of receipt entry.

It depends. Once accounting is generated and journal entries are transferred to GL the receipt number cannot be updated. Up
that point a receipt number can be edited. If there is wrong data entry a receipt can be reversed, after accounting is complete
new/correct data can be entered.

As discussed during the session on 4/15/21, the receipt summary screen shows the receipt amount as well as unapplied amou
receipt batch shows count and unapplied amount total. With these two data elements, the information can be tracked at batc
(deposit ticket number via report). The report for unapplied receipts was demoed during the OTC Reports session on 3/11/21.
However, we can revisit this topic, if needed.

Based on the configurations there are different control options and edits that can be applied. Standard edits include setting th
length of the field, numeric vs. alphanumeric or required/optional.

For reimbursable agreements with advances, a receipt is applied to the agreement. When a bill is created it knows the agreem
number and advance amount. This process will reduce the bill amount. Where there are no advances, a receipt must be enter
applied to the bill.

Yes. Closed batch indicates that all receipts have been applied to the bills and there is no unapplied amount or unidentified am
Receipts can always be added to the batch as needed which will make the batch out of balance or open as the case may go to
status of closed when all receipts have been applied.
Negative cash receipts for standard receipts (bill and customer based) are not possible in EBS. Miscellaneous receipts can be
negative or positive. When project expenditures are allocated to various projects the project auto accounting will regenerate
accounting based on the old and new project information. It is possible to allocate costs from one project to another project o
projects using an expenditure allocation in the Oracle projects module, but more information is required to answer the scenar
described.

Yes, receipts can be entered in a batch even if there is a single receipt. One voucher number is one batch number. All receipts
processed using this logic.

Yes, one deposit ticket/ voucher number is going to be entered as one batch.

Receipt entry and receipt /cash application can be done by the same person or different persons. The system is flexible enoug
allow either option. It is up to the bureaus to decide which works best based on the current business processes and future bus
processes that they want to establish.

1) The lockbox checks require ODI capabilities that were not identified as part of the BAS to-be requirements. We will need
additional information as to what NOAA requirements are for Lockbox. There is some Oracle functionality on Lockboxes, but w
to confirm the business process vs. system capability that will work for the bureaus.

2) Yes, we will have future discussions with each bureau regarding Pay.gov transactions and other interface programs such as
Seafood Inspection – the Pay.gov discussion for NOAA transpired on 5/3/2021.

The configuration of the deposit/voucher ticket number field in EBS is still pending. We are still collecting and analyzing all the
information from the data calls provided by the bureaus.

There was consensus that the batch number field will be used as deposit ticket number. That is the direction in which we wan
unless some limitations are discovered during implementation and testing.
As discussed in the session, we will need more info on OTCnet. Can NOAA please clarify – Is OTCnet number used in place of v
number?

Summary data entry is one receipt per line in the summary entry form. Based on font size anywhere from 16 - 24 receipts line
displayed in summary form which means a user can enter that many receipts in a single form. Detailed receipt entry is one for
receipt. So, to enter 16 receipts the user must open the detailed entry form 16 times and save the record 16 times to complet
similar to that of summary entry. If the same speed of data entry is used summary data entry would be faster than detailed en

Yes, during the Pay.gov discussion with NOAA on 5/3, we have covered the CIR topic as well.

During the Pay.gov discussion with NOAA on 5/3, we have covered the CIR topic. We understand the dependencies that burea
have on the design decisions for EBS. The business process to interface specific data files like Pay.Gov / CIR is under review.

For a Reimbursable Agreement, each Project/Task is linked to the Customer Agreement and Funding. When costs (expenditur
posted to a Project/Task, they are linked to the Customer Agreement in Projects. If there are multiple Customer Agreements l
to a single Project/Task, then configuration allows for each cost/expenditure to be split across each agreement. Revenue and
customer billing are then generated as a result of these expenditures.

The session was focused on the servicing side of the IAA. On slide 7, the "Orders approved by Requesting Agency" refers to th
obligation by the requesting agency (trading partner) - this is not an obligation for DOC. For the servicing side, the order will
interface to Projects in EBS, and will create a customer order which will be linked to a Project and Task. We will discuss more r
to the requesting agency process in future sessions.

The 7600A and 7600B forms can be generated from the G-Invoicing application. If it is decided that the 7600A/B forms should
saved as a PDF and attached to the GT&C and Order (respectively) in G-Invoicing, then there is an option to pull those attachm
as well as any other attachments into EBS and attach to the GT&C and Order.

The Unfilled Customer Order and Reimbursable Allotment accounting entry will be automatically generated in EBS as part of t
GINV integration and process. Once the Order is interfaced into EBS, a Customer Agreement will be created. Once approved,
funding from the agreement is linked to a Project and Task, and the funding is baselined in EBS Projects module. Once that is
complete, accounting entries will be generated to post the UCO accounting entries via Projects SLA to GL.
Standard EBS integration automatically interfaces costs that are generated from AP Invoices into Projects, and assign to the
Project/Task based on data that was entered on the PO (matched invoice) or AP Invoice (unmatched invoice). Similarly, Labor
will be posted to a Project/Task based on the interface mapping (details can be provided from the interface team). Once the
costs/expenditures have been automatically posted to the Project/Task in the Projects module, the standard Draft Invoice pro
will generate customer bills reflecting these expenditures. The Projects Draft Invoices must be approved and released in the P
module, and will then be interfaced to AR.

Yes, all documents related to each IAA will be linked together. On the servicing agency side (where DOC bureau is the servicin
agency/seller), majority of the transactions are generated and stored in the Projects module. The GINV GT&C is linked to each
created from the GT&C. Each GINV Order is linked to a Customer Agreement in Projects. Each GINV Order Line is linked to a
Project/Performance Obligation Line in Projects.

In EBS, the 7600A/GT&C will be interfaced as a GT&C and can be viewed from the GINV dashboard. Each 7600B/Order will
automatically generate a Customer Agreement in EBS. Although a Project is not automatically created as part of the interface
the GINV dashboard in EBS, the user will be able to create a new project or associate the order with an existing project. When
done, the Order Line and Order Line Shipment are used to automatically create the Performance Obligation and Perf Oblig Lin
the Project. Funding lines are then entered to associate the Agreement (Total Order Amount) with each Performance
Obligation/Line/Task. This funding is then baselined in the Projects module, and this action automatically generates the UCO a
Reimbursable Allotment accounting entries via Projects SLA and posts to GL, through standard EBS processes and integration.

1) Customer Agreement refers to the Agreement record in EBS, which gets created from the interfaced GINV Order.

2) No, but the Allotment and UCO accounting entries will eventually get created from the funding on the Agreement (see resp
above - PRJ-78 & PRJ-81).

3) Not necessarily. In keeping with Treasury terms, IAA refers to the overall Interagency Agreement, which consists of the GT&
one or more Orders. The Customer Agreement in EBS is created for each IAA Order.

4) The Customer Agreement will be created automatically by the interface when a new order is pulled from G-Invoicing. Howe
is still to be determine if it will need to be approved manually in BAS based on the approval workflow configuration we have
gathered so far.

Yes, all billing (performance) will flow through G-Invoicing. The invoice will be created in BAS as part of the G-Invoicing integra
For inflight IAA orders that are not initially loaded to G-Invoicing, there will be a bulk load capability in BAS similar to APSI. We
cover more detail on this topic when we review the process for Requesting Agency IAA's.

The GT&C will always be initiated and entered manually in G-Invoicing, and then interfaced into EBS/BAS, even for Requesting
Agency. For the Requesting Agency, the Order will be entered in EBS/BAS, and will be interfaced to GINV once approved by th
requesting agency. Once approved by the Servicing Agency in GINV (or in the TP financial system), the order will interface bac
EBS/BAS, and funds will be obligated. We plan to cover more detail on this topic when we review the process for Requesting A
IAA's.

In G-Invoicing, there is an Advance Payment Indicator on the GT&C and additional fields related to advance collections on the
These fields are interfaced into EBS as part of the standard GINV-EBS integration. We have not yet gotten far enough in the te
to understand how these fields are used in the standard integration with Project and AR, and if an additional field (like Receipt
Method or Receipt Type) will be needed to identify an Advance collection. We will continue to review this with the DMF as the
patches and testing progress.
This process will be seamless to the end user and require no action on their part. The Billing Frequency will be entered on the
in G-Invoicing, and then interfaced to EBS. This billing frequency will determine how often a bill is generated for each IAA
Order/Customer Agreement.

All of the standard batch processes, including the billing and revenue generation in Projects, interface of customer bills from P
to AR, and interfaces with G-Invoicing will be scheduled on a regular basis (actual timings/schedule TBD as part of the O&M SO

This is interfaced directly from G-Invoicing (it displays as Status in GINV on the Order Line Schedule). Treasury would need to p
more details on how this status will be used.

Customer refunds (generated from negative cost adjustments against an IAA order) are a future discussion topic for the Treas
Invoicing team. We do not yet have an answer on how Oracle or Treasury expects to handle these.

Customer refunds are a future discussion topic for the Treasury G-Invoicing team. We do not yet have an answer on how Orac
Treasury expects to handle these. See PRJ-96

Oracle EBS is designed to allow multiple activities and transaction entry/updates to occur, within and across modules, without
impacting other transactions. There are controls that do not allow two people to be modifying the exact same transaction at t
same time, but that is at the individual transaction level (and this control is a consistent capability across all modules).

The exact schedule for the GINV interfaces has yet to be determined, but our expectation is that the interfaces will run multip
times a day.

Need further clarification on the last question re: Interfaced GINV transactions affect the WIP process. Can NOAA please provi
example/business scenario of this?

The DOC GINV team will be working with each bureau on the G-Invoicing system itself. The BAS team will be coordinating wit
DOC GINV team in walking through the complete process, once we have gotten all patches from Oracle, and have all compone
the integration working, which most likely will not be until mid- to late-summer. It is part of our Sprint 4 and post-Common So
to continue to work through the released features from Oracle and Treasury.

Some examples of external/interfaced costs would include: NFC, E2, Bankcard, etc.

In addition to the functionality associated with Reimbursables, the projects module will allow DOC to budget, assign cost alloc
rules, and track costs at a project/task level to monitor budget execution. Further, the use of the Projects module which is tigh
integrated with the EBS modules allows users to enter transactions using a shorter string to drive the longer Account Code Str
Please note that the budget execution (appropriation, apportionment, etc.) will be handled in the Federal Administrator modu
Information was shared on cost transactions as a way of introducing the concepts and build understanding on how project/ta
functionality could be accomplished in EBS. As stated during the session, this functionality is not part of the standard AR soluti
This issue was identified by the PMO team and escalated as a critical need. The PMO is working on a solution to meet this
requirement, and that solution will be shared with the bureaus in an upcoming session. We will talk more about the projects b
and its ties to AR in future sessions.

The focus of this session was Direct Projects. Capital Projects will be covered in future sessions. We have a proposed Projects
calendar that is currently under BAS PMO final review.

The PMO has started conversations with the bureaus to crosswalk CM004 set up with EBS. As part of this exercise the team w
document any gaps in the attributes available or those that are needed moving forward.

The PMO has started conversations with the bureaus to crosswalk CM004 set up with EBS. As part of this exercise the team w
document any gaps in the attributes available or those that are needed moving forward.

No, in EBS, you can actually have different owning orgs for task and sub-task, if desired. Today in CBS, we know we set up only
owning org per project. Yes, expenditure org is synonymous with CBS charging org.

This isn't necessarily the same for all though depending on how a bureau decides to use it. The key takeaway from the BAS
presentation was that the current business processes on nomenclature for Project Code will not change. For TC's, we will havi
further conversations with the DMF as soon as we approve the schedule that's pending with BAS PMO.

Yes, the BFY is limited to a single year. You would need to set up a new BFY each year on X year funds. There will be discussion
the posting logic in upcoming sprints.

The PMO is assessing options to limit the administrative burden related to annual task setup. We are currently reviewing diffe
options and will share this with the bureaus when there is more information.

As discussed in the session, the PMO is researching how Project/Task can be leveraged in modules that do not offer this functi
with core functionality. This includes AR, GJ's, and WebADI (SLT). When a solution is documented, it will be shared with the bu
As highlighted before, document level corrections will be corrected in the EBS module rather than through SLT/DLA/DLCA as t
today. The BAS Core Apps team has this marked as a Priority Item and will be discussing this.

If this question is asking if the same task can be used across multiple projects, then yes, you will still be able to set tasks/subta
to meet these needs. For example, if the same task code is defined as Task 1, you can establish Task 1 for more than one proje
Task name does not need to be unique. We have the Reporting and Analysis session Cost and Expenditure-related Project Mo
reporting on 6/30/21.
Project Code has to be unique across DOC, task/subtask must be unique within the Project. BAS Core Apps has looked at all of
CBS data on Project and Task codes. Based on this synthesis, there are very few cases where the data is duplicated.
The Project and Task lengths will follow the current CBS protocols. The Oracle EBS system limitation is up to 25 alphanumeric
characters. You can refer to the Projects deck on 3/31/21 for more guidance. In terms of standardization, we will have a Proje
session coming up to discuss this with the bureaus. Now that the foundational functionality of Projects has been shared, discu
will begin on business rules/formats.

No, you should not use "O" or "0" to start your Project/Task code. Oracle will not allow users to start these with 0's. Additiona
now that the foundational functionality of Projects has been shared, discussions will begin on business rules/formats.

Now that the foundational functionality of Projects has been shared, discussions will begin on business rules/formats.

The focus of this session was Direct Projects. Capital Projects will be covered in future sessions. We have a proposed Projects
calendar that is currently under BAS PMO final review - capital projects will be discussed when we look at "Project
Types/Classifications". We need to understand how this currently works today as it relates to Sunflower assets.

Fund, BFY, and Program will be stored at the task code. Users can define these parameters by tasks and sub-tasks. This will be
business scenario discussion: the system will allow you to have more than one task with the same Fund / BFY / program code.

Templates can be leveraged when setting up Project/Task/Subtask that would reduce the need to enter each one individually.
option will be included as a solution when we discuss the annual maintenance related to Project/Task/Subtask setup. Task cod
cannot be shared across projects.

We discussed this during the Projects session on 3/31/21. You can refer to the deck for more guidance on definitions.

When submitting POET the O refers to the expenditure organization that will charge the project. In this example, if multiple O
are charging the same project the Organization provided in the POET entry would reflect the expenditure organization.
The AutoAccounting process is how the accounting string is derived from the POET attributes based on the Project / Task for
transaction items. These items will still post to the Projects Module Subledger as SLA before they are then pushed into the Ge
Ledger.

The PMO is assessing options to limit the administrative burden related to annual task setup. We are currently reviewing diffe
options and will share this with the bureaus when there is more information.

The PMO is researching how Project/Task can be leveraged in modules that do not offer this functionality with core functional
This includes AR, GJ's, and WebADI (SLT). When a solution is documented, it will be shared with the bureaus.

POET and Account Generator does not apply only to interfaced transactions. Manually entered invoices, POs would also levera
same functionality to derive the full ACS. In other words, the system will have ACS strings in it and there will be a way for user
search for the options.

Now that the foundational functionality of Projects has been shared, discussions will begin on business rules/formats. Require
need to be defined if the additional attributes are considered project or task level.

CBS Project Type may be an additional classification but more analysis is needed to finalize this concept.

The PMO has already started to work with the bureaus to crosswalk CM004 set up with EBS. As part of this exercise, the team
also document any gaps in the attributes available or those that are needed moving forward.

Fund code is part of the task code set up in EBS (FUND). EBS terminology has specific types for project type that are currently u
review. CBS Project Type may be an additional project classification but more analysis is needed to finalize this concept.

After cross walking CM004 to EBS is complete, we plan to gather examples from the bureaus to plug into the new model. The
world examples should help to highlight the setup that would be included in EBS and give greater understanding on how the v
will evolve in the new solution.
Yes, there would be capability to build on the list over time as needed.

This means the transaction has been submitted, but is pending final approval and it is en route to the appropriate folk(s) in the
approval hierarchy. Workflow requirements still need to be confirmed with bureaus.

Expenditure Org is the same as Charging Org in CBS. Organization in Projects Module on the projects screen set up is the Own
Org.

The brackets button is where the dff's are housed and at the Project Header form, we have configured the Project level ACS
segments. You can refer to the deck from the Projects discussion that took place on 3/31/21 for more guidance.

This means the transaction has been submitted, but is pending final approval and it is en route to the appropriate folk(s) in the
approval hierarchy. Workflow requirements still need to be confirmed with bureaus.

The T for Task would include Task and any lower level Subtask. If there are lower level subtasks - those would be available at t
lowest level of detail for POET.

Question does not include enough information, please resubmit, but if related to AR/GJ/Web ADI see other responses on this

This functionality is not part of the standard AR solution. This issue was identified by the PMO team and escalated as a critical
The PMO is working on a solution to meet this requirement, and that solution will be shared with the bureaus in an upcoming
session. We will talk more about the projects billing and its ties to AR in future sessions. Projects module will process projects
invoices into receivables for those items that meet those business case definitions. There is not a timetable at this point, but t
issue is being worked and any updates will be shared when they have been vetted and approved within the PMO.

Registration status will be interfaced from SAM. The business process will remain the same as it is currently at DOC to correct
update statuses.

Correct, but some bureaus use '000' as their "at minimum" task code value. This was sort of the standard within CBS, howeve
bureaus may have deviated from the standard.
Yes, but what we are saying that you can't submit a transaction in CBS without a Task. You would receive an error or would no
able to go past the field without entering one. You would not be able to approve a transaction with a null task code. So even
task does not derive fund or program in EBS, you still need at least '000' to submit a transaction.

The information is presented this way because in CBS you must have a project and task to submit a transaction. In CBS, withou
you can't submit a transaction. You would receive an error; the screens would not allow you to proceed past that field withou
inputting a value. Yes, we know that Project in CBS derives fund and program. What we are trying to say here is that in EBS, yo
must use a task to fully derive the ACS? Task must be supplied in both CBS and EBS.

Yes, you can define the level of budgetary control for projects and tasks. There are 4 project types in EBS, Direct, Indirect,
Capitalized, and Reimbursable. We will be discussing this in greater detail. However, the final calendar for Projects is pending B
PMO approval.

Burden Schedules are cost allocation in EBS. They are created in EBS maintenance screens and assigned when a project is setu
can exclude by not assigning a burden schedule to a particular project/task/subtask. There are other costing methodologies th
being discussed concurrently based on different business scenarios.

RBAC is something that OCM is currently working on. At a minimum, you need one key member.

There will be additional conversations on Project Budgeting in Sprint 3.

Cost Allocation/Burden conversations are ongoing with NOAA team members. These conversations started back in January an
wrap up in April including system demonstrations/feedback on the functionality.

The BAS Core Apps team has created a Visio that details this process. We will be sharing it with the bureaus and speaking to th
upcoming Sprint 3 conversations. This will be discussed in more detail for PRISM <> EBS data flows.

There will be ongoing conversations on whether project code level funds control is needed and where that would/wouldn’t m
sense. Several discussions have identified the ask to control budget at a lower level than the federal budget levels (appropriati
apportionment, etc.). This would be a feature that you could use.

For list of participants from NOAA, please speak with your PMO

There are ongoing discussions regarding admin activities with BAS PMO.
Because these topics are being worked concurrently the focus of this session was simply to document and highlight the relatio
between projects and cost allocation/burdens.

There are business rules to validate certain data combinations to prevent using the wrong codes in certain scenarios. Can you
provide screenshots and specific details around fund code, project number, task number, BOC, etc. From CBS?

Please provide additional information. It is not clear how this is connected to the Projects content that was presented.

Yes, it can be run at the fund level. There are also other Trial Balance reports other than the one we ran that will allow you to
Trial Balance at either a Summary or Detail level based on Fund level only.

Yes. The GTAS trial balance has all GTAS attributes that are assigned to the SGLs. This trial balance can be exported to Excel vi
and then filtered on the attributes requested.

A TAS trading partner can be setup with Agency 999 and Main account 9999. This would make this type of TP available for GTA
reporting.

The Fed/NonFed (FNF) algorithm works as follows: For SGLs requiring FNF:
1) If there is only 1 valid FNF value allowed, that FNF value will be assigned;
2) If multiple FNF values are allowed, Oracle will look at the trading partner supplier or customer setup in Purchasing and
Receivables respectively. The FNF value assigned to the supplier/customer will be used;
3) If multiple FNF values are allowed and no trading partner supplier setup is available, then an exception will be generated an
reported
SGL 640000 requires an FNF, a TPID, and a TPMAIN. As multiple FNF values are allowed, it will search for the supplier assigned
line item generating the 6400000 JV entry. The FNF value on the particular supplier will be used for the 640000 JV entry.

We will need more information as to the suppliers and/or employees receiving the outlay advances. Ad hoc reporting using BA
built-in reporting tool (FSG) is a potential solution which can be used to pull the 480200 balance to be reported and split the b
into various FNF values based on the type of suppliers assigned to the transactions (e.g., Reimb Agreement agency (assign F if
is a federal agency), employee advance (assign N based on Federal guidelines), etc.) making up the balance.

If there are additional attribute domain values that need to be reported on, then those scenarios need to be communicated to
PMO for review.

The Budget Execution transactions are part of the Fed admin module (FV). The SGLs assigned to these transactions are derive
the Transaction Types defined in FV. The attributes mentioned can be required to be entered as part of the transaction type s
Therefore, FV will transfer the approved, reserved transactions to GL where a JV will be generated for the activity. If manual JV
entered in the GL to SGLs requiring these attributes, then the GL JV form will require the user to input values for those attribut
Most GTAS attributes will be assigned based on TAS/Fund setup, reporting code setup, and supplier/customer Trading Partner
attribute values. Oracle has noted that TP TAS (TPID & TPMAIN), Authority Type Code, and Reduction Type attributes cannot a
be derived; therefore, any SGL requiring these attributes used in any GL JV will require the JV user to enter a value for those
particular attributes. The list of SGLs requiring these attributes are fairly minimal.

The GTAS reports will be consolidated at the bureau level. System does allow it to run the reports multiple times, therefore bu
can run it separately. The final decision on whether the GTAS process will be run by DOC or bureaus hasn't been made yet as t
discussions are still ongoing. If corrections are need to be made, bureaus will have to coordinate among each other to commu
that reports will required to be rerun based on changes.

By default, these DATA Act attributes in EBS are not enabled for users to enter values manually. The PIID, Parent Award ID attr
will need to be interfaced in EBS through in PRISM. These are automatically populated in PRISM when the FPDS record is creat
through the PRISM - FPDS interface. FAIN and URI will be from Grants.

Yes, Data Act attributes is setup as a Global Flexfield which is available for a user to enter values as part of the JV setup. GTAS
attributes are also setup as Descriptive Flexfields for JVs as well.

Cohort will utilize the 9th segment of the ACS, a flex field.

GTAS Attributes will be shared across bureaus as these attributes are configured at ledger level. These attributes are standard
Treasury compliant. Please provide details of why would these attributes need to be overridden. Please provide example scen
which require change in the attributes.

Consistent with purchasing the BAS solution as a SAAS, Oracle will release patches as Treasury comes up with new requiremen
These patches will need to be applied as part of the maintenance. The maintenance efforts will be discussed at the time of setti
O&M model. DOC will apply these patches as received, and will no longer update the code directly as we have done in the pas
An updated Fund Code crosswalk will be shared with the bureaus during 5/20 Budget Entry and Funds Control session.

The assignment of Cohort Year is based on the mapping of Cohort year segment of ACS on the Federal Financials Options form
Fed Admin module. Based on indication of the Cohort Year Segment from ACS, and TAS Attribute setup to indicate Financing A
Code attribute of the TAS, the GTAS File Generation program will know to populate Credit Cohort Year attribute on GTAS for re
funds based on Cohort value provided in ACS segment at transaction level.

Oracle does provide capabilities to automate the process. This will be discussed further down the lane during training discussi
Implementation years.

These are two different transactions from PO and AR modules. The left one is on Supplier setup screen, and the right one is on
Customer setup screen.

Yes, you can report both the TPID and TPMAIN on a JV line. The descriptive flexfield (DFF) will show a Trading Partner input w
JV line has an SGL that requires both TPID and TPMAIN. The Trading Partner field on the DFF is seven(7) characters long so a 3
character TPID along with a 4-character TPMAIN can be input in the Trading Partner field.

Slide 13 shows attributes under [ ] box, and on slide 17 shows attributes (on the right screenshot) under ( ) box. ( ) box contain
attributes for Trading Partner TAS, BETC, DATA Act attributes such as PIID, FAIN, URI, Parent Award ID.

Noted

Noted. A more detailed walkthrough of such scenarios can be covered during UAT as it will require more data within the syste
show better reports.

GTAS and Data Act reports can be run by Main Account or for all funds within a bureau. There is no Treasury requirement to r
on funds, only on TASs. Main Accounts are normally tied to TASs. You would need to run a trial balance at the fund level to se
numbers for a specific fund. The GTAS reports would consolidate all funds tied to a specific main account when reporting the
trial balance by main account.
That is still under consideration. We will make sure to add another comment in the outcome tracker of what the to-be will be.

Yes, all bureaus will need to close at the same time because of single instance. Each bureau will have to process their activities
subledgers. Once all bureaus finish the activities, the subledger period will be closed. There will be process in place to ensure t
environment access is control during the time of closing. This can be discussed/included in the O&M model.

The GL can be open for multiple periods so you can still continue to review your prior period balances and process current per
transactions. Even if you close the period, you can still report for any accounting events that have happened. Let's say we clos
March and in April you can still go back and look at entries in the inquiry mode. If you want to make adjustments you can open
target period. You should be able to open the period if you have to make adjustments post month end close. Security can be s
so only certain responsibilities can open and close the periods. There are ways to address how to make sure an entry does not
posted into the wrong period.

We will make a note of this. System can have two periods open at the same time. Part of getting transactions approved should
include validating accounting details entry. This can be included in the approval process to ensure user enters valid GL period d
this timeframe of adjustments when two periods are open.

We will need to get into Financial Statements at a later time. Some of them, we will need to do some compilation on. We are n
point now to talk about financial statements. We will try to address that when we get into the financial reporting aspects with
and Data act.

The specifics of financial statements, tie-points etc. will be visited at a later time. Currently, we are not at the point to talk abo
in detail. We have received NOAA's information of these topics. We will review the provided details. Sprint 4 will include a Rep
& Analysis session, which can be used to discuss these items further in detail.

It is where we process a number of budget related transactions. This is where we set up the appropriations, apportionments, a
allotments for processing those particular transactions. Then can be set up for additional project funding and will ultimately be
for controlling funds further down at the projects level, but it all starts with the Federal Financials Module. It is also where we
track of any type of confirmations that come in from the Treasury for disbursements. Allows us to identify trading partners tha
be used for IPAC.

The BOP equivalent is within the Projects module. There will be a series of sessions on the Projects functionality in the comin
weeks that will cover this functionality in greater detail.

In total, BAS will include 14 periods, 12 regular Fiscal Calendar Year periods, and 2 adjustment periods (1 OpenYR, 1 CloseYR).
other subledgers (AP/AR/PO/PA), where users can manage their own periods (not GL Accounting), Federal Financial module d
include its own periods. Federal financials periods are in sync with GL periods. Please see Additional Comments field for screen
of Accounting Periods structure within BAS system.
EBS transactions first hit the sub-ledger and are subsequently moved to the General Ledger at a to-be determined specified in
Non-transferred activity is any transactional data that has not hit the GL yet.

The Create Accounting program generates accounting from subledger transactions which have funds reserved with no funds
exceptions and have been approved for processing/posting via Oracle workflow. Once a transaction has a status where funds
reservation and approval has occurred, the next iteration of the Create Accounting program will identify the transaction for
generating accounting and posting to the GL. Bureaus and departments can have many transactions "in-process" but which ar
funds reserved and/or approved. These transactions will be out of scope to the Create Accounting program.
Yes, there is no shut down period. User can enter the transactions as the system runs Create Accounting Process.

Once a month-end is reconciled to the GL and closed in the subledger systems, the subledger period will be closed so that new
transactions cannot be entered into the subledger for that timeframe. The new period will be opened at this time so that new
transactions can be processed in the new period. Simultaneously, the GL module will open a new period so that any new JVs o
interfaces can get booked to the new period, but the old GL period will remain open for any accruals and/or close adjustments
expected that only a small group of people will be permitted to enter manual GL JVs and the GL JVs entered will need approva
order to be available for posting. Therefore any risk of entering a JV into an incorrect period can be addressed with the appro
The PA module will act as a subledger to the GL. It will reconcile and close a month-end in the same manner as all other suble
If a period needs to stay open for closing adjustments in PA, then this policy and procedure can be set. Oracle can accommod
this.

Unposted AR or AP transaction means that the transaction isn't fully approved and processed. This may be due to timing, or it
be due to additional research needed to identify the proper accounting for the transaction.

Hold Name is where the reason why an invoice is on hold is explained.

The Budgetary Execution Transaction Register Report would be used for any transactions occurring in Federal Financials. All
resources, anticipated, CRs, supplementals, recoveries, warrants, recissions; it represents all budgetary resources. It acts as an
listing of all transactions generated during a specific timeframe and also shows their status (posted, unposted, or incomplete).
report can be used for reconciling the Federal Financials budget execution subledger to the GL and to help reconcile and funds
control/availability issues.
Most of these Reports by default are in .txt format but can be imported into Excel using import wizard feature in Excel.

There would be a consolidated schedule to coordinate among all three Bureaus.

In other agencies, this has been done in a matter of days. The opening and closing of the months takes very little time. The
reviewing of numbers usually takes a day or so.

1st period is OPENFY (Open Fiscal Year Period), which is an Adjustment Period for beginning Fiscal Year activity. This OPENFY i
first day of October. The entire month of October is period 2.

Closing process in BAS will be standardized. Therefore, all bureaus will need to close together.
In EBS, the GL can be open for multiple periods so you can still continue to review your prior period balances and process curr
period transactions. Even if you close the period, you can still report for any accounting events that have happened. Let's say w
closed March and in April you can still go back and look at entries in the inquiry mode. If you want to make adjustments you ca
open a target period. You should be able to open the period if you have to make adjustments post month end close. Security c
set up so only certain responsibilities can open and close the periods. There are ways to address how to make sure an entry do
get posted into the wrong period.

Labor interface discussions will begin in June/Sprint 3. Detailed discussions on this topic will occur at this time.

Labor interface discussions will begin in June/Sprint 3. Detailed discussions on this topic will occur at this time.
The BAS solution for the current SLT files is being worked as a priority topic, there will be working sessions on this with the bur
the upcoming weeks.

The WEBADI solution is being looked at to be modified to incorporate project and task.

Cost Allocation discussions have been occurring and various scenarios are being discussed including the over/under scenario.

By default, the Trial Balance Reports are in Text format only. The Report can be copied over to Notepad in a .txt file then can b
opened in Excel.

The Trial Balance data within EBS will be real time, given the accounting process will be run on daily basis. Users can generate
report to see the real time data directly from EBS.

The Unbilled to Billed receivables will happen during Month-End in EBS AR module after Projects module is successfully closed
accounting is dependent on how Revenue and Invoicing happens in Project. Therefore, it is required that Projects module is cl
entirely before running the Unbilled to Billed receivables accounting.
ACS and Project/Task information can be visible to users through transactions. Users can access relevant transactions to view
accounting information tied to those transactions.

Subledger Exception Reports are best run at the service set level (NIST Service Set, NOAA Service Set, Census Service Set). So,
this report using NIST responsibility will show data for NIST as well as all NIST serviced bureaus.

Create Accounting can be setup to run in a loop so that reserved, approved transactions are available to post. No other inform
will be submitted for posting until the transaction has gone thru funds check, funds reservation, and approval.

The BAS system is designed to stay open while the close process is occurring.

EBS is a software as a service (SAAS) product compared to the custom CBS solution. There will be tools for users within a bure
query data as needed such as Tableau within EDW. Backend access will be restricted to certain roles and responsibilities. Disc
on roles and responsibilities (RBAC) will occur in Sprint 4.

Non-SAM suppliers will be added manually in the AP module.

Grantees will be discussed in Sprint 4.

FedAdmin module houses setups that are pertinent to the supplier creation process in the AP module. The ability to down sel
from the FedAdmin module to the AP module. SAM data will refresh to PRISM on demand and non-SAM data will integrate to
PRISM on demand from EBS. PRISM will receive refreshed data automatically in the event a new SAM supplier is required for
transaction, likewise from EBS for non-SAM information.

Within EBS, each supplier will be assigned to one or more operating units (OU), which corresponds to a bureau(s), i.e. NOAA, N
CENSUS. SAM data will come into EBS and be available to pull the supplier record by the bureau requiring the record.

This will be discussed in Sprint 4.

This will be discussed in Sprint 4.

"On demand" means "real time". Data will refresh automatically in the event a new SAM or non-SAM supplier is required for
transaction for the one record.

This will be discussed in Sprint 4.

UEI is not yet implemented, but is expected to replace DUNS by April 2022. SAM refreshes on a scheduled daily basis to EBS a
demand to PRISM. EBS refreshes all supplier data to PRISM on-demand.

For SAM suppliers, the DUNS/UEI number would be integrated to EBS as the supplier number. The current configuration for n
SAM supplier numbers is user generation. The CoreApps team will confirm the recommendation based on the criteria for the
supplier number with BAS PMO in Sprint 4.

This will be discussed in Sprint 4.

Registration status will be interfaced from SAM. The business process will remain the same as it is currently at DOC to correct
update statuses.

If a supplier is flagged under DNP/Expired/Inactive, that supplier will not be paid. Further details on the DNP integration, its
associated indicators will be discussed during the DNP session on 6/25.

SAM would match supplier records via DUNS, TIN and CAGE. There is a "Tax Registration Number" field that can be utilized in
foreign suppliers.

Reporting is available to query foreign supplier sites in EBS. The supplier would be associated to a "Tax Country". That field w
associate the appropriate foreign tax information to the supplier.

No, the current configuration will have NOAA serviced bureaus under NOAA.

The supplier can be used for purchasing and also for processing payments. The address from SAM will be the address populat
EBS for all SAM supplier records.
If the remittance information is incomplete, an error will be displayed in EBS.

Other Pay.Gov transactions can be interfaced, but each scenario will need to be reviewed to determine if the standard functio
applies.

Lockbox is meant for interfacing receipts and applying the receipts to transactions in one step. If transactions (AR Bills) are rec
against actual customers and the lockbox file references the transactions the receipts will be created and applied against the
transactions. This is the best use of lockbox. If receipts are recorded at summary level or in cases where transaction details exi
other systems(APEX) lockbox may not serve the purpose. So, each bill and its receipt details must be known to answer the que
precisely.

The number of batch(es) will be accordingly to how it comes from CIR. Therefore, if the CC payments come as separate batche
will be assigned its own voucher/deposit number.

One voucher number is going to be recorded as one batch. There will not be multiple batches in a Receipt Batch.

From the Pay.Gov session for NOAA on 5/3/21, ALC should remain the same as it is today. The existing architecture will be
maintained. If there is one ALC for each bureau now, the same architecture will be maintained in EBS.

Discount terms and 1099 flags are all checked once the award comes into EBS. These checks are part of the vendor manageme
EBS.

During the conversion process, the net view of all active awards will be migrated to PRISM and migrated to EBS. Any new actio
taken on these awards, such as modifications, will interface from PRISM to EBS following the same process as non-converted a

In PRISM, users will select the invoice matching type, such as two-way, three-way, or four-way, and the value will be sent to E
through the interface. The remaining actions, including receipts and acceptance, will occur in EBS. This functionality will be ava
on day one.

IPP is now the recommended E-invoicing platform. IPP will support invoice matching needs (specifics to the business process w
reviewed as part of the implementation). More details on the implementation will be rolled out beginning in Sprint 4.

Every funded line item on an award in PRISM must have an associated delivery line. PRISM assigns an ID to each delivery line a
each funding line in the format of delivery ID-funding ID, which can be viewed on the Funding tab.
Examples of financial validations that will be included on PRISM awards include checks that the obligation has an associated
commitment in finance and checks that the de-obligation amount does not exceed the available balance on the funding line. T
integration development, including the full list of validations and associated error messages, is still in design and development
can be fully viewed during UAT and training.

There are separate processes for deobligating funds and closing awards in PRISM. The PRISM closeout process was covered du
the Post Award Management session held on 4/14/21 and will be validated during the Post Award Management Configuration
Validation Session planned for 6/23/21. In summary, remaining funds can be deobligated from awards in PRISM and EBS by
processing a modification in PRISM that will be sent through the interface upon contracting officer approval. Additional closeo
actions, such as completing the applicable closeout checklist and moving the award to a "Closed" status in PRISM, can be take
the Post Award | Closeout tab in PRISM by a user who has the appropriate level of access.

EBS reports will be leveraged to identify the awards that contain funds that need to be canceled. Once the awards have been
identified, modifications for deobligation will be initiated in PRISM and sent through the interface to EBS upon contracting offi
approval.
PRISM will display rolled-up invoice and payment information received through the interface. These details are still being discu
as part of the integration development. Any details related to additional charges, such as interest fees associated to vendors, c
found in EBS.
The requisition and purchase order can be queried in the Purchasing module as read-only. These requisitions/POs will not be
editable in the financial system (EBS).

This scenario would be best explained during a system walkthrough. 1099 suppliers will be discussed during Sprint 4.

In PRISM, users will select whether an item is a supply or service. If this value needs to be changed after an award is released,
modification would need to be issued.
Thank you for providing some examples of reporting types for NOAA. We plan to cover PRISM reports during the 6/2/21 and 6
Common Solution sessions.

Regarding the financial report mentioned, an open orders report is available as standard functionality in EBS. The report exclu
closed, final closed, and cancelled orders.

TBM is currently under review with BAS PMO and CIO. The TBM requirements are still in progress and have not been fully vett
Based on those discussions, we can provide additional information on what BAS will provide to support those to be confirmed
requirements.

As discussed during the session, there are two types of suppliers that can be set up in EBS: a Standard Supplier or an Employee
employee supplier type was also discussed during the CWT/E2 session on 5/18, which is where we showed an employee as th
supplier. The fields in these two supplier setups are different in that the employee setup asks for employee values vs. compan
information. The existing business process of entering new employee data should not change. We will not be linking HR data
of BAS. We plan to discuss employee access as part of the RBAC sessions.

As discussed during the session, there is only a 1099 checkbox in EBS. However, a payment group will be set up for foreign ven
We plan to discuss 1099 suppliers in more detail in Sprint 4.

All supplier records in CBS will be loaded to EBS during conversion.

The existing business process of entering a non-SAM record should not change.
Supplier data in PRISM will be synced with EBS.

Yes, they are two distinct data tables.

For a customer refund the following two conditions must be satisfied.

1. The customer must exist in AR.

2. There should be a receipt with an unapplied amount exceeding zero dollars in AR.

Since a customer must exist in the AR system for a refund, that is the name (customer) to which the system will send the refu
back. Vendors (SAM/Non-SAM) from AP are not visible in AR screens, which includes refunds. So, this scenario is not possible

The only way an AP vendor is visible in AR is if the same supplier is set up as a customer and the user (you) establish a link betw
them. This scenario again requires that vendor be set up first as a customer and then link the supplier to customer. The AR
customer is a must for refunds to process. AR refunds can be processed without setting up a supplier, but the other way aroun
not possible.

SAM supplier updates will flow from SAM to EBS daily. From EBS, the supplier data will go to PRISM. In the event of supplier
reference data requiring an update, PRISM will be able to pull that information from EBS or SAM (i.e., on-demand). On-deman
refresh would occur in an instance between scheduled interim updates to EBS.

Non-SAM suppliers and SAM suppliers can be queried in EBS.

Here are some of the fields to search a supplier: Supplier Name/Supplier Number/Taxpayer ID/Tax Registration Number/or Em
Number/Operating Unit/DUNS Number/Cage Code/Taxpayer Number/Legal Business Name.

We plan to discuss more details on how to search suppliers during the training sessions.

Bill to in EBS is Remit to in PRISM. The supplier information, including Bill To/Ship To locations, sent from EBS to PRISM will be
sync. The supplier information will be refreshed as required.

Yes, each vendor site would have a bureau specific string. During non-SAM supplier creation, the accounting will be associate
that point. Yes, there will be cross-validation rules in place to prevent a NIST user, for example, from utilizing the NOAA accou
string.

The close process will be run for all bureaus department-wide at the same time. The close schedule for preliminary closes and
closes will require coordination by all bureaus. Preliminary closes can be run multiple times and can be streamlined to be run f
departments at the same time. (Example: preliminary closes could be run nightly or twice a day (noon & nightly) so that new J
adjustments can be posted and closed out. Then bureaus could re-evaluate their balances following the close and determine
they stand with any additional, outstanding close entries).
Bureaus should close using the 2-step BAS process. If additional entries are needed for posting after the Preclose process (i.e..
or on-top adjustments), policy and procedure will need to be setup to provide guidance for re-opening a closed period in the B
ledger for additional posting and re-running the Reclose process. Policy and procedure for these scenarios will be determined
future date.

We would need more information on what "Priority Order" is in the CBS system to answer.
Sequence Number does allow for multiple year-end closes to occur where a priority can be placed over certain TASs and SGL
accounts to close prior to other TAS and SGL accounts close.

The decommitments generated from the BAS year-end program will be interfaced back to the PRISM source system for PRISM
requisition closeout/cancellations. The BAS integration team is aware of this requirement.

All cut-off dates will be determined by the DOC and bureaus as currently done. The BAS system close dates will be incorporat
the close schedule. Cut-off dates for feeder systems, whether simultaneous or not for bureaus, will be determined in a coordi
fashion by the DOC department and bureaus.

The close process will be run for all bureaus department wide at the same time. The close schedule for preliminary closes and
closes will require coordination by all bureaus. Preliminary closes can be run multiple times and can be streamlined to be run f
departments at the same time. (Example: preliminary closes could be run nightly or twice a day (noon & nightly) so that new J
adjustments can be posted and closed out. Then bureaus could re-evaluate their balances following the close and determine
they stand with any additional, outstanding close entries).

The BAS close process does require that GTAS bulk files are updated prior to running the year-end close process. The GTAS bu
does populate attributes as part of the bulk file generation. Most attributes are defined at the TAS, Fund, SGL, reporting code
transaction levels. The year-end process maintains the same TAS, Fund, SGL, and reporting code during the close; therefore, t
assigned attributes at the TAS, Fund, SGL, and reporting code level will close with the same attribute values as the previous ye
Transaction assigned attributes are captured as part of the GTAS bulk file generation process and are taken into account with
year-end close.
In you example with the 4871 closing to 4801, the Apportionment Category Code is assigned at the fund level. Therefore the f
with Category A 4871 balances will close to the same fund with Category A attribute with the closing SGL of 4801.
Hyperion will be used for the preclosing and closing process to run GTAS validations & edits along with Tie-points against the G
and Data Act files to determine if there are any additional edit issues that must be addressed before quarterly, year-end filing
roll-forward.

Period 1 is an Opening Balance period. The balances in period 1 will be the roll-forward balances from the close process of the
previous year. This period is not available for posting by users. Only beginning balances are included in this period.
Period 13 is the month of September activity and balances. Since period 1 is an opening balance period, September will be pe
(1 period + 12 month periods = period 13). October will be period 2, November will be period 3, etc. Pre-close adjustments ar
recorded in period 13 (i.e.. year-end accruals, year-end corrections, etc.)
Period 14 is a Close Balance period. Period 14 activity includes the post-close balance adjustments which close-out to the roll-
forward beginning balances of the new year. This period is not available for posting by users. Only post-close adjustments are
included in this period.

There is no standard capability in EBS to restrict users by Open/Close FY. This will need to part of business process to ensure th
system is accessed by limited users based on their tasks at the time of Year - End activities. It is always recommended that a ne
Fiscal Year is opened to transactional activities only when previous year is closed and fully processed.

As part of year-end, there will be Closing Schedule that will be determined. It will include all closing activities for all BAS modu
including PO, AP, AR, Projects, Federal Finance, and GL.

There are ongoing conversations on Project/Task rollover and the associated maintenance related, and as those details are fin
they will be shared with the bureaus.

We have a copy of the NOAA YEC plan, and will review it and factor in any additional discussion points in the next YEC session
will take place in Sprint 4.

Currently the YE closing execution report is in a text format. The report can be setup to be in an XML format which can be
downloaded and Excel can convert to Excel format upon opening the file.

This means that the data integration will be seamless to the end user.

A user will not have to perform any manual activities in terms of the data sent from E2 to EBS, as that will be taken care of by
communication layer of the interface. Users would then pull the invoices that interfaced for payment in the Payments Modul

They will be identified in the supplier table as an employee.

When UAT begins, this future year trip will be tested in the environment. In the meantime, we will take this scenario down on
Outcomes tracker to keep visibility of this scenario for testing.

Yes, there are controls in EBS that would prevent the budget year from being used if the actual travel does not occur in that p

Census will still be able to send 1 year, 1 prior year, and 1 future year of POET to E2. This process will not change for BAS.

CWT/E2 and EBS Payables each have their own system checks that validate data individually. These would serve as the "audit
checks.

NIST will continue to receive the files in the same way that is done today and will not have to extract the data to exclude
NOAA/CENSUS from the master file.

Relocation/mLINQ integration will be discussed in Sprint 4. Where the CC number will be available on the invoice is still under
discussion, however, all other data would be validated in the CitiManager tool. EBS would validate the POET attributes, as tho
sent over from the Projects module to Citibank.

Change of tickets would need to be updated in the E2 system. That updated information would then be integrated to and cor
in the financial system.

We would need to understand why the process is manual today for hotel/rental cars so we can provide a recommendation.

Correct, system checks are in place to prevent duplicates/un-authorized claims from being processed for payment.

Yes. The system would also reject the individual transaction if the incorrect ACS is assigned. Any inactive data would be flagge
the system and would not flow through to payment. Responsibilitiy of tasks will be discussed in future RBAC conversations.
This business scenario would need to be tested, however, if the P-Card is charged that would be handled by the SP3 process.

We have taken a note of this and will make sure to include this in the next session.

We have taken a note of this and will make sure to include this in the next session.

We have taken a note of this and will make sure to include this in the next session.

Correct, the relocation system will be discussed during Sprint 4. The current deployment for NIST follows the NOAA go live in
next fiscal year.

Commitment accounting will ensure the funds check will fail if the funds are no longer available. This scenario will be tested i

This concern is noted, and conversations continue on the appropriate level for tracking BFY. However, none of the scenarios
currently being evaluated would remove BFY from the hierarchy as described here.
We understand the new functionality associated BFY will represent a change from past functionality related to FCFY specificall
relates to carryover into a new FY. The ability to preserve the appropriation year for the life of the funds versus current proce
should outweigh the impacts of this change, but we acknowledge this will need to be a focus for training on how funds are ma
if/when they carry over into a new FY.

At this time, we are recommending bureau code start the numbering format for project codes. For Census, their bureau code
EBS does systematically allow for 0's to start the project code, however, we were originally recommending not to start with ze
since it can be similar to the letter 'O'. However, with Census, we will have to make an exception.

Yes, we are recommending the bureau code be prefixed to all project codes to allow for uniqueness across EBS.

At this time, we are recommending the task code to be 5 characters in total. The first 3 (alpha numeric) plus 2 digit fiscal year
identifier. We are currently assessing whether the pros/cons of appending the BFY to the front or end of current task code.

Naming conventions used prior to BAS will remain if a bureau's business process deems it necessary. The only factors to consi
conversion is that the bureau code will be appended to the 7 digit project code + 0 on the end for all converted CBS projects.
As long as these are data elements identified for reports they will be in the EDW to be able to pull reports on. The Organizatio
be a part of the ACS string so in terms of document drill down, it will be available. The CBS project type does not equally trans
EBS. Today's CBS Project Type translates into EBS Project Type + additional attributes which we think we can fit into Project
Classifications. Examples of project type are Direct, Indirect, Reimbursable. If bureaus require additional reporting type
categorization of their projects, it could still be accomplished if desired through Classifications. It would not, however, drive an
allocation or TC like in CBS. It would be mainly used for reporting mechanisms.

A whiteboard session is scheduled for 6/14 to discuss 3 options.

BFY will be part of the task code, there has not been a final decision on whether it should be appended to the front of existing
codes or on the end. This should be resolved as the conversations continue on this topic.

This business process will be taken into account as we further our discussions on project/task codes. We are planning a future
session to cover workflow topics such as this.

Yes.

Yes, either way. EBS allows for the ability to have a project relate to 1 or more fund codes. However, it is not a system require
A bureau could establish a "business process" rule to allow or not allow projects to relate to multiple fund codes. This could b
further verified, confirmed/approved through the use of approval workflow so that the established workflow can be validated
accuracy.
As part of the Project/Task discussion, critical additional attributes do need to be considered. At Task Level, we may have a lim
set of fields. At Project level, there is greater flexibility as you can have as many project classifications as you need (comes wit
maintenance requirement). Additional information on project classifications is being planned for a future discussion including
whether it would be necessary to track some classifications through flex fields on the task instead of the project.

Agreed. If DoS has an 8 character limitation, the BAS DoS interface will need to work within the confines of those requiremen

Does DoS allow for more than 3 digit task?

Agreed, that additional feeder systems will also need to be assessed on impact to the larger project and task numbers.

A response to this question may be better to demonstrate visually and we can target this for the 6/14 in person session. It is n
required that a project contains multiple funding sources. In addition, there are ways to mitigate this through system controls

The BAS PMO is working on identifying a solution for year over year maintenance/set up for task codes.

The concept of operations for project/task maintenance will be discussed at a future session.

End Date is not required, but may be useful when a Project and/or task has no remaining open obligations. Future training an
discussion on this should help to determine best practices related to Project Start/End Date usage.
The CBS project type does not equally translate to EBS. Today's CBS Project Type translates into EBS Project Type + additional
attributes which we think we can fit into Project Classifications. Examples of project type are Direct, Indirect, Reimbursable. If
bureaus require additional reporting type categorization of their projects, it could still be accomplished if desired through
Classifications. It would not, however, drive any cost allocation or TC like in CBS. It would be mainly used for reporting mecha

Once you have used a task in the system on either a PO/req or an expenditure exists, you are no longer able to update the Tas
Number. See attached word document for the message notifications you will see. In addition, you can change the Task name,
description, dates, make it chargeable, make it billable/nonbillable, can update any of the DFF values (which is where the
Program/Fund/BFY will potentially go).

For projects, on the Project Header, you can not change the Project Number like the Task, when expenditures (costs) exist and
are Oracle requisitions/purchase orders + feeder system impacts. You can not change the Budgetary control setting (funds ch
project/task) once you have an approved cost budget established.
Other elements of the Project header can be changed such as the Project Name, description, dates (in so far they align with ta
dates), classification values, key members.